Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
IDEs produce some config files per project/workspace
IntelliJ has it's .idea/ folder and it's .iml files.
Eclipse has its .classpath and .project files.
Eclipse Maven integration used to need a m2e-lifecycle configuration in the pom.xml (not sure if this is still the case)
I've seen projects in the past,
where Eclipse artifacts (.classpath, .project) have been stored in the SVN and it usually broke every developer's workspace.
where even the m2e-lifecycle configuration was prohibited
where the m2e-lifecycle configuration was allowed but not .classpath or .project
where subsets of the .idea/ folder is checked in because it contains the run-configurations
typically .gitignore files contain IDE specific files.
I tend to leave all IDE artifacts out of the sourcecode, including configuration, except the listing of IDE artifacts in the .gitignore.
But I wonder, what are good reasons for / against checking in
IDE generated artifacts (like .classpath or *.iml)
IDE specific configurations (i.e. in maven poms)
into the SCM?
Or is it a general No-Go?
If you use Maven/Gradle/SBT there is no point to commit *.iml files as they are re-generated from Maven/Gradle/SBT. Artifacts are also automatically generated form these build systems, so unless you creates your own IDE artifacts you should not commit artifacts configuration.
See also How to manage projects under Version Control Systems.
See also similar question: Which files in .idea folder should be tracked by Git?.
Why you should omit them:
you want to be able to build your projects with the build tool of your choice (e.g. maven, gradle, etc.) on any build server you like (that actually supports them)
you want to be able to load the project with any IDE (no quirks in the IDE project settings to get it to work somehow)
Why you should commit them:
all use the same IDE in the project (and maybe also: all have the same directory structure; note: I would never force anyone to use a particular IDE or fixed directory structure, so I actually don't like this particular point ;-) )
OR (probably more valid): you are the only one to use the project and want to (re-)setup everything rather quickly/smoothly
Regarding IDE settings, such as formatting settings, etc. something similar applies. As long as all use the same IDE sharing makes sense. If you use different ones, you may need to use your version-control-tool to actually format the code (formatting commit hook, formatting before comparing different revisions, etc.) or everyone should rather agree on a common formatter.
Regarding IDE specific settings in build-files like m2e-lifecycle:
... it really depends. I would rather try to use plugin configurations that actually work without additional m2e-lifecycle-boilerplate. In the end it doesn't make the build-file any more readable ;-)
Summarizing (my opinion ;-)) I only commit IDE specific files when working alone on a project and in any other case I omitted committing them as did teammates. If they were committed in a project I usually didn't reuse it (or only the formatter via plugins) as I mostly was on another IDE.
Related
I've started using git externally from Eclipse and have been running into issues with the auto-build functionality trying to compile the hidden .git folders. This question shows how to exclude them on a per project basis. Is there anyway to do this globally or per perspective?
There is currently no such possibility.
When you create a Resource Filter it modifies the .project file of your project folder inside the workspace, however I do not recommend creating those filters manually, since they have an ID generated by Eclipse and the chance that you have problems is greater. It is preferable to put the properties individually in each project than to do this directly in the configuration files.
As #brandizzi said in the question comment, there is an open bug a few years ago but eclipse did not prioritize this in the development of the new versions, dealing with an improvement with low priority, however in my opinion would be another great feature to facilitate the settings of the development environment.
As the tool is very good and free we can not criticize much, but it's the tip for Eclipse.org:
There are many developers wanting this functionality.
Reference:
Eclipse Workbench User Guide > Concepts > Workbench >
Resource filters
Should I put .classpath, .project files and .settings files on SCM when working with Maven project with m2eclipse plugin? Theoretically every developer can grab the sources and import maven projects.
Due to your experience is it better to do this that way or to put Eclipse files to SCM too? Some developers are using InteliJ so I don't want the projects to be Eclipse specific. It seems that the .project file may change according to the set of installed plugins, e.g. change buildCommand from org.eclipse.jdt.core.javabuilder to org.eclipse.wst.common.project.facet.core.builder etc.
Please share your knowledge and experience.
In my experience, you should not include .classpath, .project or .settings. All the information needed to re-import the project is in the pom file, so long as you use "import existing maven projects".
If you put all those local ones, you are likely to end up having SCM changes for irrelevant things, such as different order of entries, local modifications someone made to their project preferences, etc...
As per my experience , it is safe to check-in .project file as it defines the nature and other properties which is useful for developers who will be creating new workspace. Many times, custom facets needs to be added via Eclipse and you may want to share it with other members of your team provided all others use the same IDE for example RAD.
They won't have to go through the pain of again setting and changing project nature, so it might help. Even we had to share our .settings folder in most cases because ppl were facing issues with workspace setup. So all depends on the need and it might help.
One situation in which it is very convenient to have Eclipse project files under version control is when you have Java code automatically generated by plugins. Eclipse removes missing source directories from its configuration before code generators run.
UPDATE
With recent Eclipse releases (I'd say since Juno, certainly since Mars) this is no longer the case.
Over the years the m2e plugin was greatly improved and nowadays there is really no need to store project settings in your SCM, as these settings are properly recreated from the project POM. This has the added benefit of allowing the use of different Eclipse releases with the same project.
When I commit a web appliction to source control should I also include the .project & .classpath files ? I don't think it should make any difference either way as other users who use the project should have the same project settings ?
This is the sort of question that gets people bent out of shape in a debate that never ends. You basically have two camps:
Only put source code into the source control system. Each developer chooses their own IDE and manages their own project configuration. Setting up your IDE after getting source code from the repository will be tricky. If one dev changes project dependencies, they have to explicitly communicate that so that all other devs update their project configurations. There are some tools that try to address this problem, like a Maven plugin that will attempt to generate Eclipse project metadata from pom.xml, but all have their limitations. Groups that go this way favor the purity of not restricting developer choice in IDE over the convenience of having Eclipse projects across the team that just work.
Standardize on Eclipse. Put all Eclipse project metadata into source control. This includes .project, .classpath and the entire contents of .settings. Basically, the only thing that you don't want in your source control repository is content marked as derived in Eclipse. You can check that in right-click->properties. Taking this approach ensures that developers can get started coding immediately after getting the project from source control. No additional configuration required. Also, when one dev changes project configuration, the rest of the team will see the same change on next sync.
Choose the approach that makes the most sense for your team.
For ClearCase, including the .project and .classpath can make a difference when you are using the IBM ClearCase plugin for Eclipse.
That plugin will work better if it can rely on those (versioned) files being there, right next to the sources (as opposed as being in the Eclipse workspace, which doesn't necessarily contains said sources).
In general, nothing generated should go into repository. Those files are generally generated by IDE or maven. However, sometimes you may need to click a button or execute a command to get those generated.
i would include them.
The .project file have plugin info (e.g. maven, ant, pdt, wst, aspectj, findbug..). It is essential if it is not a plain java project.
.classpath contain the classpath. it is needed if you use jar files.
I would say that all files - including .project and .classpath - should go to source control, to ensure that everyone in the team has the exact same setup.
I'm looking for advice regarding best practices for sharing an Eclipse project among developers.
It seems clear to me that each developer should have his/her own Eclipse workspace. However, projects seem to loan themselves better for many users to use the same project, e.g., if several users are working on a particular component, they are all likely to need to use the component's project, since if they each had their own project, they'd each have to set up and maintain the same project dependencies, etc. Looking to see if this is what other folks do or if their are reasons to give each developer his own project for a particular component.
Also, if the recommendation is to share a project, what are recommendations for configuration managing an Eclipse project? In the past we have used ClearCase, but we are now looking to change to Git or SVN. In the ClearCase world, it would seem advisable to do frequent checkins and merges to help the team stay up to date. Again, I'm looking for opinions from folks who have already lived this.
Thanks for any recommendations or external "how to" books or websites!
Thanks,
Ken
Sharing an Eclipse project doesn't cause any problem. Just put the .classpath, .project files and the .settings directory (and any project-related config file/directory that Eclipse generates at the root of the project) under source control.
Also, avoid using absolute paths in your project (for external libraries, for example), since all the developers don't necessarily have the same setup and use the same locations.
Git, SVN or ClearCase : it doesn't matter : all allow sharing Eclipse files.
We put the entire eclipse project folder under version control (with an svn:ignore for the directory containing the compiled classes).
This allows us to share not only the build configuration, but also launch configurations (with the proper VM-parameters), the configuration for compiler warnings the team considers relevant, and the formatter configuration for the coding conventions in use. We can also set text file encodings that way.
...avoid using absolute paths in your project
Good point.
We've had some issues with this in ClearCase. Our third party libs were placed in a different part of the filesystem under version control. So to avoid absolute paths to the libs we added an ant script. The script would copy the libs to a view private directory that was directly under the project root.
We then added a builder to the project to make sure that the script was run first at every clean + rebuild.
What Eclipse specific files should I add to the VCS (Subversion, GIT, etc...) when sharing an Eclipse project?
What I have here:
.autotools
.cproject
.project
.settings/
Just stumbled upon this and had the same problem some time ago, so I will try to share my experience.
First it depends on who are the other users of the VCS or better what programs they will use. If they do not use Eclipse these files will only pollute their projects.
If they do use Eclipse the files might be of use to them, but in my latest project I did not include them for the following reasons:
Everyone had another system which meant other paths for the includes and so on. Concluding from this I surveyed the contents of these files to see if they should be used:
.cproject: The includes are listed here, so you will have different files in the list on each platform. -> leave out
.project: Found some environment dependent paths here too. Maybe it also has a problem when there are different plugins installed. -> leave out
.settings: It might make sense sometimes to share the settings but usually it is each developers own decision. -> leave out
.autotools: I did not use this, so I cannot say anything about it.
Summary
It seems best to leave those files out of the repository.
For Eclipse this introduces the problem of creating a new project when importing from the VCS. In this case you should give advice on how to configure the project to set it up correctly.
When you put the project files into the VCS those who do not use Eclipse will probably have less problems than those who do, because the files are simply ignored at their site while the Eclipse users will have to reconfigure them for their system.
Maybe there is some better way to share those projects but I did not find one yet.