.classpath and .project files are *meant to be versioned* #805
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As is clearly stated in the [eclipse documentation](http://wiki.eclipse.org/FAQ_How_do_I_set_up_a_Java_project_to_share_in_a_repository%3F). This gitignore has lead to much confusion in SO - please ammend I would guess the same is true for .pydevproject and .cproject but can't be sure/do not have any references on those Also .launch configurations are generally meant to be versioned when saved under project location. See for instance : http://stackoverflow.com/a/337317/281545
|
Thanks for the reference links! |
aroben
added a commit
that referenced
this pull request
Nov 8, 2013
.classpath and .project files are *meant to be versioned*
|
Thank you |
drothmaler
pushed a commit
to drothmaler/gitignore
that referenced
this pull request
May 27, 2014
.classpath and .project files are *meant to be versioned*
|
I use to version them in my ANT days. Eclipse by default generates absolute path but we can change them to relative paths. This way importing projects will be easy in shared environment. I still believe there is a benefit in version them. |
|
It only made sense to version these back in the Ant days. With Gradle and Maven, eclipse plugins handle the classpath within eclipse (or when the project is generated by the build script). Either way, these are really bad to version in modern practices. |
|
Plus, when the default setting of Eclipse is to write paths that can't be shared, the default setting of .gitignore should be to not share them. If someone wants to change the defaults, they can. |
arcresu
added a commit
that referenced
this pull request
Jan 15, 2015
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.
|
See the commit linked above and its commit message - this change has now been reverted so we're ignoring |
u9E9F
pushed a commit
to u9E9F/gitignore
that referenced
this pull request
Jul 8, 2017
.classpath and .project files are *meant to be versioned*
u9E9F
pushed a commit
to u9E9F/gitignore
that referenced
this pull request
Jul 8, 2017
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.
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As is clearly stated in the eclipse documentation.
This gitignore has lead to much confusion in SO - please ammend
I would guess the same is true for .pydevproject and .cproject but can't
be sure/do not have any references on those
Also .launch configurations are generally meant to be versioned when
saved under project location. See for instance :
http://stackoverflow.com/a/337317/281545