Which Eclipse files belong under version control?

Question

I am using WP json api to get dat a from my wordpress site.It is working fine when i access the url from browser. but when i try to call it from file_get_contents() or using curl,it returns 404 page .

 $url = 'http://example.com/api/menus/get_menu/?menu_location=mainmenu'; // this url works from browser
 $data = file_get_contents($url);
 echo $data; // returns 404 page html

Solution 1

Metadata should not be managed in source control. They contain mostly data relevant to your workspace.

The only exception is the .launch XML files (launcher definition).

They are found in

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

And they should be copied into your project directory: When your project is refreshed, those configurations will be displayed in the "Run configuration" dialog.

That way, those launch parameter files can be also managed into the SCM.

(Warning: Do uncheck the option "Delete configurations when associated resource is deleted" in the Run/Launching/Launch Configuration preference panel: It is common to soft-delete a project in order to import it back again - to force a reinitialization of the eclipse metadata. But this option, if checked, will remove your detailed launch parameters!)

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

should be in your SCM (especially .project and .classpath according to the Eclipse documentation).

The goal is that anyone can checkout/update his/her SCM workspace and import the Eclipse project into the Eclipse workspace.

For that, you want to use only relative paths in your .classpath, using linked resources.

Note: it is better if project-dir refers to an "external" project directory, not a directory created under the eclipse workspace. That way, the two notions (eclipse workspace vs. SCM workspace) are clearly separated.

---

As ipsquiggle mentions in the comment, and as I have alluded to in an old answer, you can actually save the launching configuration as shared file directly in your project directory. All launching configuration can then be versioned like the other project files.

(From the blog post Tip: Creating and Sharing Launch Configurations from KD)

Solution 2

I am currently working on a project where we have the .project and .cproject files under source control. The idea was that settings related to library paths and link directives would propagate across the team.

In practice it hasn't worked very well, merges almost always come back in a conflicted state which need to be deconflicted outside of eclipse and then the project closed and reopened for the changes to take effect.

I wouldn't recommend keeping them in source control.

Solution 3

It's worth nothing that CDT configuration files are not source-control-friendly. There's a bug filed for .cproject files changing very frequently and causing conflicts, see Sharing cdt-project files in repository always causes conflicts.

Solution 4

Some projects, like those using Maven, like to generate the .project files based on POMs.

That said, other than that - .metadata should NOT be in source control. Your project will have to make a determination about whether projectdir/.settings does, based on how you plan to manage standards and such. If you can honestly trust your developers to set up their environment based on the standard, and you don't have to customize anything special for any project, then you don't need to put them in. Me, I recommend configuring every project specifically. This allows devs to work on multiple projects' stuff in the same workspace without having to change default settings back and forth, and it makes the settings very explicit, overriding whatever their default settings are to match the project's standards.

Only difficult part is making sure they all stay in sync. But in most cases you can copy the .settings files from project to project. If there are any you specifically don't want in source control, do the equivalent of setting svn:ignore for them, if your SCM supports it.

Solution 5

The .classpath file is definitively a good candidate for checking into scm as setting it by hand can be a lot of work and will be difficult for new devs getting into the project. It is true it can be generated from other sources, in which case you would check in the other source.

As for .settings, it depends on the settings. This is a grey area, but some settings are almost mandatory and it is convenient to be able to check out a project, import it in Eclipse and have everything set up and good to go.

At our project, we therefore maintain a copy of the .settings folder called CVS.settings and we have an ant task to copy it to .settings. When you get the project from CVS, you call the 'eclipsify' ant task to copy the default settings to the new .settings folder. When you configure settings that are needed by everyone developing on the project, you merge those back into the CVS.settings folder and commit that to CVS. This way saving settings in SCM becomes a conscious process. It does require devs to merge those settings back into their .settings folders from time to time when big changes are checked in. But it's a simple system that works surprisingly well.

View more solutions

Comments

[dingo_d]

And when you do a print_r($data); what do you get? If I'm not mistaken it should return a json object, no? In that case you just need to decode it, and work with it.

[Shijin TR]

it return 404 html,from wordpress

[dingo_d]

Have you tried doing like described here?

[VonC]

Nope, you can have relative paths in your .classpath. See stackoverflow.com/questions/300328#300346.

[juckele]

We use Maven 1 and 2, and it only generates the .project file if you ask it to. And even if you do, it does so based on the contents of the POM, so if another developer has already done that step for you and checked the result into version control, why not take advantage of that?

[Ipsquiggle]

A (IMO) much better work flow to working with anything in .metadata for the .launch files, is: when you edit a launch configuration, on the common tab, choose Save as > shared file. This directly drops it in the project folder, so it can be SCM'd with the rest of the project.

[VonC]

@lpsquiggle: good point. I have completed my answer to better reflect that possibility.

[jfritz42]

Why should .project be in SCM? For example, I want to use a code metrics tool which causes changes in .project when enabled. I would not want to force that on all users of the project.

[VonC]

@jfritz42: if you do a local and punctual change valid only for you, then make that versionned .project ignored for the time being just for your workspace. But don't deprive all the other users of the common Eclipse project definition they can quickly import in their Eclipse workspace, just because you happen to have one extra definition that would fit only your need of the moment.

[Vincent]

Is the launch configuration must be at the root of the project? I put them in a sub directory and it is not loaded with the project when we do a checkout.

[VonC]

@Vincent: see stackoverflow.com/questions/952290/… (PROJECT_LOC/.setting works automatically, but other locations requires a bit more work).

[garyp]

Is this a correct "take-away": 1. Have your SCM ignore .metadata 2. Save launch configurations in the project. 3. Smile, everything is now ok.

[VonC]

@garyp the main idea is to have enough information in your VCS for anyone accessing the versioned content to be able to "": see stackoverflow.com/questions/2818239/… and stackoverflow.com/questions/116121/…. That presumes you have only relative paths in your project files, not absolute path dependent of one specific dev environment.

[garyp]

Thank you. I'll study those links carefully, but already I notice that in the first of your links one answer starts "Definitively yes" while the very next one starts "Defininitely no". Google is full of varying, newbie-unfriendly advice. I understand the goal, but how to get there is the issue. I come from Xcode where source and user options are cleanly separated from Xcode-generated and compiler-generated output so that this question has a simple answer. To the Eclipse newbie, it appears that those files are mixed together and scattered about. I'm looking for a simple understandable answr

[BrainSlugs83]

I come from VisualStudio land, and I second @garyp here -- this is really a hot mess -- if Eclipse needs to make temporary and/or unnecessary-to-track per-user files, it should put them somewhere else, so that the project and build definitions can be tracked and all the temporary garbage doesn't get in the way. Isn't there some more official guidance from the Eclipse team somewhere? (It's pretty clear the eclipse team doesn't unit test [or if they do, they don't do it effectively] but at least tell me they use source control! XD)

[BrainSlugs83]

Sounds like a pretty incoherent / inefficient team if they're not using the same dev. tools, project, debug, and build definitions, etc. -- Next you're going to tell me not to use a common coding standard or JDK. -- Ideally, a user should be able to pull down a project from source control and jump right in without a lot of additional setup or instructions. So this answer is just plain unacceptable for me.

[BrainSlugs83]

Yikes -- this bug is six years old and still not touched. Clearly source control support is not a priority for the Eclipse team!

[matbrgz]

In my experience this tend to break in various ways when you update Eclipse to a newer version, or switch between flavors.

[Christopher Barber]

It should also be noted that the .cproject file contains configuration information you would rather not force other developers to have to manually recreate. Ugh.

[A. Rodas]

It is way more inefficient to deal with the conflicts in the preference files during a merge, just because someone opened the project from a new workspace - this is a nightmare in large projects. Besides, forcing to use the same IDE with exactly the same configuration sounds like an unnecessary restriction.

[axiopisty]

I agree with [~agnul]. Projects should be using some build tool (gradle, maven, ant, etc...) and the IDE should be able to open and configure the project from the build tool configuration file (build.gradle, pom.xml, build.xml, etc...) No IDE files should be version controlled. They are all developer specific files, not project specific files. They simple do not belong in version control.

[Loenix]

But when you want to share this project publicly as a source (as a framework), you should not share eclipse project files... what we should do ?

[cp.engr]

"project-dir/.settings/* should be in your SCM" - This forum post suggests otherwise. Why do you think it should be in SCM?

[VonC]

@cp.engr When I wrote that answer 8 years ago, that worked pretty well, but yes, you can ignore it if you want.

[Athul Nath]

Please do not answer with a comment/question. Understandably, your rep is too low to comment, but that still does not mean answers should be used to make comments as an alternative. It would be preferable if you deleted this.

[Muhammad Taufik Rizky]

because he got the same return 404 html, it may got same case with me,. i think my comment got a value added