Create m2e.gitignore #1217
Create m2e.gitignore #1217
Conversation
This makes sense when using Maven and eclipse (with m2e plugin).
|
+1 |
|
Bump! |
|
This also goes for the Eclipse Gradle plugin. The only reason to version these two paths today is if you are not using dependency management - and the number of people in that group are shrinking. As long as this makes it in somewhere, I'll be happy. Why is this taking so long to merge? :-) |
|
I don't use any of this software myself so I don't have a feel for what is helpful. I was originally just going on the strength of the PR which removed the rules from the main template originally. Although it does seem that a lot of people are asking to have them added to the main template so perhaps that is the right move anyway. It would be helpful if somebody could find some documentation or explain in more detail why you would or would not want to ignore these files because I don't really know enough to make a decision, hence the inaction. The main issue is that the eclipse documentation quite explicitly asks you to version the files, and when in doubt we normally follow official documentation unless there's a good reason to do something else. |
|
In short: In Long: In theory, this file could be shared with others so they did not have to manually configure their eclipse classpath. In practice, I never saw it work out quite so well due to eventual bloating of the classpath with needless jars or jars that only existed on one person's machine. Mind you, many people back then also used to check their dependent jars into version control along with their source. Dependency management tools like Gradle and Maven have done away with all that of course. But they also integrate nicely with Eclipse and manage the project classpath dynamically. The .classpath file is basically rebuilt based on changes to the build.gradle file or pom.xml file. Effectively, this renders the whole point of checking in the .classpath moot as it is easily rebuilt by the Maven or Gradle plugin. The .project file is another animal completely. It basically describes what plugins should be applied to the project as configured in the Eclipse UI. Again the theory is it could be shared and creates a happy world. But due to different eclipse versions people may have, different plugins installed, etc. sharing the .project file actually causes more issues. And I've seen many projects unable to open due to a bad .project file - requiring one to delete it anyway (which then of course, when someone recreates it, they inevitably check it in over the old one and end up breaking someone else's environment). The bottom line is, regardless of what the eclipse documentation says, these are very much internal configuration files for eclipse and best left out of a repo. |
|
I should agree with @segfly.
IMHO, there is no point in version controlling those files, I never see it working, never knew anyone who wanted to do this, even then, it will probably not work due to random environment differences. Eclipse documentation doesn't consider m2e, by the way. I first created a PR adding this to the main |
|
@segfly and @caarlos0 Thanks very much for taking the time to explain. It seems that the original PR which took those rules out of the Eclipse template based on the documentation was the wrong move. I'll reintroduce the rules there as you've both suggested in separate PRs and add notes in several places so we don't relapse in the future. |
|
@arcresu seems good to me. |
Fixes #1217. Once again ignore .classpath and .project in the Eclipse template. This has been requested in multiple PRs such as #1338 and #1221 and is essentially a reversion of #805. I copy the explanation for this change from the discussion in #1217 by @segfly: *In short*: I can't point to any counter-documentation off the top of my head. I just know from experience these files pollute a project's repo without adding value - that is, unless everyone contributing is using Eclipse and no-one is using dependency management. And even then, the guidance provided by the eclipse docs is bad advice. *In Long*: The .classpath file is used by Eclipse to maintain the project's classpath during automatic compile (every save of a file). In the olden days, one would manually configure the project within the Eclipse UI and include all the dependent jars necessary to compile your project. Eclipse then wrote that configuration out to the .classpath file. In theory, this file could be shared with others so they did not have to manually configure their eclipse classpath. In practice, I never saw it work out quite so well due to eventual bloating of the classpath with needless jars or jars that only existed on one person's machine. Mind you, many people back then also used to check their dependent jars into version control along with their source. Dependency management tools like Gradle and Maven have done away with all that of course. But they also integrate nicely with Eclipse and manage the project classpath dynamically. The .classpath file is basically rebuilt based on changes to the build.gradle file or pom.xml file. Effectively, this renders the whole point of checking in the .classpath moot as it is easily rebuilt by the Maven or Gradle plugin. The .project file is another animal completely. It basically describes what plugins should be applied to the project as configured in the Eclipse UI. Again the theory is it could be shared and creates a happy world. But due to different eclipse versions people may have, different plugins installed, etc. sharing the .project file actually causes more issues. And I've seen many projects unable to open due to a bad .project file - requiring one to delete it anyway (which then of course, when someone recreates it, they inevitably check it in over the old one and end up breaking someone else's environment). The bottom line is, regardless of what the eclipse documentation says, these are very much internal configuration files for eclipse and best left out of a repo.
|
Done in the above commit. Thanks! |
|
@arcresu Thank you! |
Fixes github#1217. Once again ignore .classpath and .project in the Eclipse template. This has been requested in multiple PRs such as github#1338 and github#1221 and is essentially a reversion of github#805. I copy the explanation for this change from the discussion in github#1217 by @segfly: *In short*: I can't point to any counter-documentation off the top of my head. I just know from experience these files pollute a project's repo without adding value - that is, unless everyone contributing is using Eclipse and no-one is using dependency management. And even then, the guidance provided by the eclipse docs is bad advice. *In Long*: The .classpath file is used by Eclipse to maintain the project's classpath during automatic compile (every save of a file). In the olden days, one would manually configure the project within the Eclipse UI and include all the dependent jars necessary to compile your project. Eclipse then wrote that configuration out to the .classpath file. In theory, this file could be shared with others so they did not have to manually configure their eclipse classpath. In practice, I never saw it work out quite so well due to eventual bloating of the classpath with needless jars or jars that only existed on one person's machine. Mind you, many people back then also used to check their dependent jars into version control along with their source. Dependency management tools like Gradle and Maven have done away with all that of course. But they also integrate nicely with Eclipse and manage the project classpath dynamically. The .classpath file is basically rebuilt based on changes to the build.gradle file or pom.xml file. Effectively, this renders the whole point of checking in the .classpath moot as it is easily rebuilt by the Maven or Gradle plugin. The .project file is another animal completely. It basically describes what plugins should be applied to the project as configured in the Eclipse UI. Again the theory is it could be shared and creates a happy world. But due to different eclipse versions people may have, different plugins installed, etc. sharing the .project file actually causes more issues. And I've seen many projects unable to open due to a bad .project file - requiring one to delete it anyway (which then of course, when someone recreates it, they inevitably check it in over the old one and end up breaking someone else's environment). The bottom line is, regardless of what the eclipse documentation says, these are very much internal configuration files for eclipse and best left out of a repo.
This makes sense when using Maven and eclipse (with m2e plugin).
I'm not sure if it makes sense to put it in
maven.gitignore(since I could use maven but not use eclipse at all), and it doesn't make sense aseclipse.gitignore, because not everyone uses maven.Either way, when using eclipse and maven, it doesn't make sense to not ignore those files.
There is no official documentation regarding this subject, but it is a common practice.
Please see #1211 for details.