I don't want to force people into using a specific IDE for development, so our projects look basically like this:
SomeProject
src
lib
build.xml
No IDE specific files whatsoever.
However, many people prefer Eclipse and it is their valid complain that it is annoyingly difficult to set up an Eclipse project from an Ant build file if that project is checked into a VCS. That's a very old bug, so I don't really expect it to be fixed soon.
I don't want all those weird Eclipse project files in the project root, but if it was the only way, I would accept having the eclipse project files in a subdirectory "eclipse". I thought Eclipse's linked resources were capable of just that, but I was wrong, it doesn't really work.
How do you solve this problem? Are you checking in the .settings directory. etc. into your project's root?
If I don't want certain files in the CVS or SVN I add them to the ignored files (Context menu > Team > Add to SVN/CVS ignore). You might have to enable seeing them in the Package Explorer (little triangle in the upper right corner of the view > Filters > uncheck .* resources). I usually check them in though, as given they are hidden files they don't disturb much if you don't need them but are really useful if you do.
Related
Which Eclipse files is it appropriate to put under source control, aside from the sources obviously?
In my project, specifically, I'm wondering about:
.metadata/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
If there are any of these for which it depends, please explain your guidelines.
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)
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.
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.
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.
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.
I'd say none of them. They most likely contain information that is relevant only to your workstation (I'm thinking about paths for libraries and all). Also what if someone in your team is not using Eclipse?
Consider:
.classpath
.project
.launch
These SHOULD be in version control as long as you stick to using project-relative paths. This allows other developers to check out the project and start working right away without having to go through all the setup pain that other developers went through as well.
You might be tempted to include .metadata in version control as well so Eclipse developers can check out an entire workspace and have it preconfigured with all the right projects, but it includes a lot of user specific information that anytime anybody works on it, it will change, so I would advise to NOT INCLUDE .metadata. It's easy to build a local workspace just by importing all existing Eclipse projects.
I have spent too many hours configuring eclipse workspace settings for new colleagues (and myself). What I ended up doing eventually was copying my own .metadata to the new developer machine.
If you are working on a team, then I think the following are very good candidates to keep under version control:
Installed JREs and their names
Server Runtime Environments
Java Editor Templates
Version Control Keyboard Shortcuts
Plugin settings that do not provide project specific settings
Maven settings
Preconfigured Perspectives
...
I haven't tried to put anything in .metadata under version control, but I'm using version control for these files for ten years now:
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
The main reason is that Eclipse sometimes damages those files. Without version control, you will get weird and hard to track errors. With version control, you can immediately see "Why is it trying to deploy test classes???" or "Why is Maven and Eclipse using the same classpath?" (leading to https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605).
With version control, you can see when it happens and easily go back to a working set of config files.
If you use m2e: You can import the project now with the fast "Import existing project" instead of the slow "Import Maven project".
The drawback of this approach is that Eclipse seems to randomly change some of those files. Most plugins keep them stable but some use HashMap instead of, say, LinkedHashMap so the order of elements changes all the time. This means there is an additional step when you commit: Check for any modified settings and handle them, first.
It also means that the whole team has to agree on some standards: Like which warnings should be enabled. It's interesting that many people see this as a additional problem - as if they weren't working together.
In my experience, it takes a couple of weeks until those files stabilize. Partly because you gradually learn how to tweak Eclipse, partly because people learn what not to touch. You can think of this as lost time or time spent to improve the quality of your work environment (like keeping your desk uncluttered).
There is a bonus advantage of the "Commit settings first": It gets people to commit more often and in smaller pieces (i.e. more like "one thought at a time" instead of "on feature at a time plus a thousand of other, unrelated things that I just happened to stumble upton ... what was I working on again?").
As a seasoned developer, I've come to prefer the "small commits" way of working; it's just easier to stay on track and you tend to sort your thoughts and changes into smaller, more manageable steps. This helps to reduce the level of complexity. Everyone can juggle with one ball, no one can juggle with 20.
PS: For certain setting files, I have unit tests to make sure known errors don't creep in like the "trying to deploy tests" in WTP. That helps in the initial phase "commit everything, I'm too busy" phase.
Every time I boot Eclipse I get the error "The project description file (.project) for my project is missing".
As other StackOverflow answers have show, this is easy enough to fix: delete package from Eclipse and import it again. However, if I close and reopen Eclipse the error will be back. I have not found a permanent solution yet.
I have my workspace in my Dropbox, but at some point I decided it was time to start using Git. I don't really get Git but they say you have to put the .project file in your .gitignore because it is computer specific.
This I feel is the origin of the problem, but if I don't do any git related activities (push, commit, etc.) I still get this error.
How do I fix this once and for all?
A .project is a Eclipse-specific file that tells Eclipse about how the project's struture is placed in the project's hierarchy.
It's normal for this file (and other Eclipse specific files) to not be committed because other people participating on the same project may use other IDEs of their choices (intellij, and so on), so the content committed in your VCS is 'neutral' for IDEs.
When you create a project from inside Eclipse, the .project file shall be created along. But when you import into Eclipse an existing project, there are ways to generate locally the .project , .classpath and other Eclipse-required files. Maven, Gradle and Ant are some examples of tools that do this.
Finally, I recommend to keep these files in .gitignore so the project's contents in VCS will remain neutral to IDEs. So you will not bother other people using other IDEs.
So, the steps are:
Check out the project
Generate the eclipse files using maven, ant or gradle. If your project already uses a tool such as these, thats nice
Check if the project is OK inside eclipse (compiling, no errors)
Add the newly generated eclipse files to .gitignore
commit and push the .gitignore.
.project is not machine-specific as long as everyone on your team has the plug-ins installed for that kind of project. .classpath might be if you don't do things right. This is your project, though, so commit your .project.
Keeping .classpath clean largely revolves around keeping machine-specific paths and references out of it:
Set the project's JRE using an Execution Environment. It is an indirect way of saying what version you need, then the IDE figures it out for that machine. The stored value defaults to using the name of your default Installed JRE in the preferences, which is very machine-specific.
Put the jar files you need into the project, or into another project that this one can refer to. They go into source control as well for the sake of repeatability, unless you're using a tool like Maven, in which case be specific about the version you require where ever you state that dependency and make sure the relevant M2E plug-ins are installed.
After I import my maven project to eclipse, it created eclipse project files in my maven project. How do I clear them out?
After your comment "if I dont clean the project files, how to I hand it over to someone else? If they dont use eclipse would they be appreciate all those extra files unrelated to the project?" I have understood your need.
The best way to achieve it is to use a version control system (VCS) like git, svn etc. and add inside your project tree a special file call .[VCSofYourChoice]ignore. For example for git this file would be .gitignore for svn it would be .svnignore.
Once you created this file you add rules to exclude files or directories you don't want to share on your version control system of your choice. To find the syntax to use google it with keywords ".[VCSofYourChoice]ignore syntax".
Eclipse and eventually every IDE create specific files, in order to save project structure and other internals. Some of them prompt you to select in which folder you want to save these files, for example IntelliJ, but I am sure eclipse as well. So you every time you use and IDE and you import a project, some files are going to be generated. The cleanest way is to 1) select to save them in a folder not related with the actual project, and as it already suggested do not commit them and add them in an ignore list, on your VCS of choice (e.g git)
Running OSX.
I have used eclipse for years as a Java developer. I am now messing with all kinds of new technologies but still find myself using svn (don't ask its not my descision). Anyways I don't really like SVN command line as I find it almost impossible to sort through merge conflicts.
With that I was thinking about using eclipse (w/ subclipse plugin) as my SVN client whenever I need to do SVN type things. The one problem that I have found is that eclipse loves to create a .project file. I would never want to check this in as no one else is using eclipse. I know that I can add it to svn:ignore, but that has to actually commit that ignore to SVN as well, which I do not want to do either.
Anyway to create eclipse projects without the .project file. I know sounds dumb because I am sure that eclipse needs the .project file for all its projects. Would be nice just to create an SVN project (not Java project) and have eclipse leave off any other crap.
ideas?
There is no way to create an Eclipse project without the .project file (at least none that I know of), but you can tell Eclipse which files to ignore, as well.
Just go to Preferences -> Team -> Ignored Resources and add the pattern .project.
This setting is purely Eclipse-internal and does neither affect your global svn-ignores (defined in ~/.subversion/config) nor will it add any files to the repository.
Also, when checking out folders from SVN using Eclipse, make sure to create a General Project, not a Java Project, so the .project file is the only file Eclipse creates.
.project is actually not the only file that will be generated - depending on the "project natures" you add to a project.
To really separate the project from the source folders, you'll have to create the project in a separate folder - say the workspace - remove the original source folder and add the source folders as external links - see: Project Settings/Java Build Path/Source.
Which Eclipse files is it appropriate to put under source control, aside from the sources obviously?
In my project, specifically, I'm wondering about:
.metadata/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
If there are any of these for which it depends, please explain your guidelines.
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)
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.
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.
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.
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.
I'd say none of them. They most likely contain information that is relevant only to your workstation (I'm thinking about paths for libraries and all). Also what if someone in your team is not using Eclipse?
Consider:
.classpath
.project
.launch
These SHOULD be in version control as long as you stick to using project-relative paths. This allows other developers to check out the project and start working right away without having to go through all the setup pain that other developers went through as well.
You might be tempted to include .metadata in version control as well so Eclipse developers can check out an entire workspace and have it preconfigured with all the right projects, but it includes a lot of user specific information that anytime anybody works on it, it will change, so I would advise to NOT INCLUDE .metadata. It's easy to build a local workspace just by importing all existing Eclipse projects.
I have spent too many hours configuring eclipse workspace settings for new colleagues (and myself). What I ended up doing eventually was copying my own .metadata to the new developer machine.
If you are working on a team, then I think the following are very good candidates to keep under version control:
Installed JREs and their names
Server Runtime Environments
Java Editor Templates
Version Control Keyboard Shortcuts
Plugin settings that do not provide project specific settings
Maven settings
Preconfigured Perspectives
...
I haven't tried to put anything in .metadata under version control, but I'm using version control for these files for ten years now:
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
The main reason is that Eclipse sometimes damages those files. Without version control, you will get weird and hard to track errors. With version control, you can immediately see "Why is it trying to deploy test classes???" or "Why is Maven and Eclipse using the same classpath?" (leading to https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605).
With version control, you can see when it happens and easily go back to a working set of config files.
If you use m2e: You can import the project now with the fast "Import existing project" instead of the slow "Import Maven project".
The drawback of this approach is that Eclipse seems to randomly change some of those files. Most plugins keep them stable but some use HashMap instead of, say, LinkedHashMap so the order of elements changes all the time. This means there is an additional step when you commit: Check for any modified settings and handle them, first.
It also means that the whole team has to agree on some standards: Like which warnings should be enabled. It's interesting that many people see this as a additional problem - as if they weren't working together.
In my experience, it takes a couple of weeks until those files stabilize. Partly because you gradually learn how to tweak Eclipse, partly because people learn what not to touch. You can think of this as lost time or time spent to improve the quality of your work environment (like keeping your desk uncluttered).
There is a bonus advantage of the "Commit settings first": It gets people to commit more often and in smaller pieces (i.e. more like "one thought at a time" instead of "on feature at a time plus a thousand of other, unrelated things that I just happened to stumble upton ... what was I working on again?").
As a seasoned developer, I've come to prefer the "small commits" way of working; it's just easier to stay on track and you tend to sort your thoughts and changes into smaller, more manageable steps. This helps to reduce the level of complexity. Everyone can juggle with one ball, no one can juggle with 20.
PS: For certain setting files, I have unit tests to make sure known errors don't creep in like the "trying to deploy tests" in WTP. That helps in the initial phase "commit everything, I'm too busy" phase.