0

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?

Gerald Mücke
  • 10,724
  • 2
  • 50
  • 67
  • I would say it is General a no-go. – Jens Aug 28 '18 at 14:16
  • nonsense, either it helps to commit them or harms. It depends. – Meo Aug 28 '18 at 14:26
  • _"...it usually broke every developer's workspace..."_ contradicts my experience. In Eclipse the `.project` file contains the natures of the project, e. g. Maven nature and in the `.settings` subdirectory project-specific configuration, e. g. compiler warning, formatting profile, etc. So the question is whether everyone should follow the same or their own rules for e. g. source code formatting. – howlger Aug 28 '18 at 15:00

2 Answers2

3

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?.

Andrey
  • 15,144
  • 25
  • 91
  • 187
2

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.

Roland
  • 22,259
  • 4
  • 57
  • 84