8000 Ignore Eclipse .project and .classpath when using build tools Maven or Gradle by baincd · Pull Request #3710 · github/gitignore · GitHub
[go: up one dir, main page]

Skip to content

Ignore Eclipse .project and .classp 8000 ath when using build tools Maven or Gradle#3710

Closed
baincd wants to merge 1 commit intogithub:masterfrom
baincd:ignore-eclipse-build-plugin-gen-files
Closed

Ignore Eclipse .project and .classpath when using build tools Maven or Gradle#3710
baincd wants to merge 1 commit intogithub:masterfrom
baincd:ignore-eclipse-build-plugin-gen-files

Conversation

@baincd
Copy link
Contributor
@baincd baincd commented Apr 25, 2021

Reasons for making this change:

Eclipse .project and .classpath files should be ignored when using a build tool like Maven or Gradle. However, when not using a build tool, these files should be under source control.

Links to documentation supporting these rule changes:

There has been alot of back and forth on the .project and .classpath files within Eclipse, but I think this comment sums it up nicely.

The consensus is that these files should not be ignored in all Eclipse projects. However, when a build system such as Maven or Gradle is used, these files should be ignored because they will be generated by the Eclipse plugin for the build tool. Therefore, adding these files to the Maven and Gradle gitignore files should cover all scenarios.

@bdougie
Copy link
Contributor
bdougie commented May 7, 2021

Please use this file instead. https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore

@bdougie bdougie closed this May 7, 2021
@baincd
Copy link
Contributor Author
baincd commented May 8, 2021

@bdougie I kindly ask that this PR be reconsidered.

How to handle the .project and .classpath files has gone back and forth pretty much since the beginning - These files were originally included in Eclipse.gitignore in 2010 (4b3ed39,ac35a76), then removed in 2013 (#805), then added back in 2014 (#1338), then removed again in 2017 (#2336).

The reasoning for removing these files from Eclipse.gitignore is because Eclipse projects which do not use a build tool like Maven or Gradle benefit from having these files under source control. Per Eclipse's documentation:

Make sure that the .project and .classpath files are under version control. These files must be stored in the repository so that other users checking out the projects for the first time will get the correct type of project and will get the correct Java build path.

The problem is when using a build tool like Maven or Gradle, the .project and .classpath files are generated by the respective Eclipse build plugins. In this case, having these files under version control is problematic as each developer's Eclipse instance regenerates these files, causing constant conflicts, noise, and developer confusion and frustration.

Therefore, to correctly handle all scenarios, I suggest adding these files to Maven.gitignore and Gradle.gitignore. This would keep these files under version control if only using Eclipse, but ignore them if also using maven or gradle.

There is also precedent for this solution, as there are other examples of Eclipse files being included in non-Eclipse gitignore files.

Thank you,
-Chris

@ChristianCiach
Copy link

@bdougie

I am not convinced that you actually understand the intention of this PR, because your answer makes no sense in this context. I think you closed this PR prematurely.

We are using https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore, and this template correctly doesn't exclude .classpath and .project. It would be wrong if it would do so. But these two files should be ignored by git if they are auto-generated by tools like maven or gradle, otherwise there could be conflicts.

I think @baincd is absolutely right to ignore these files in Gradle.gitignore and Maven.gitignore.

@jglick
Copy link
jglick commented Sep 2, 2021

generated by the respective Eclipse build plugins

Along with .factorypath and .settings/, at least in the case of the Java support in VS Code, which I suppose is derived from Eclipse JDT.

@baincd
Copy link
Contributor Author
baincd commented Sep 3, 2021

@jglick .factorypath and .settings/ are already defined in /Global/Eclipse.gitignore, which I think is appropriate. These files are not generated based on the maven or gradle configuration.

The confusion is with .classpath and .project, which Eclipse's documentation confusingly recommends being under version control. That recommendation makes sense if neither build tool is used. But when using either maven or gradle those files are generated each time based on the maven or gradle configuration - which causes issues when those files are version controlled. That is why I recommended ignoring these files only if using maven or gradle, but not for all Eclipse Java projects.

@jglick
Copy link
jglick commented Sep 3, 2021

These files are not generated based on the maven or gradle configuration.

Are you sure? I get e.g.

<factorypathentry kind="VARJAR" id="M2_REPO/javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar" enabled="true" runInBatchMode="false"/>

as a result of that JAR being defined in my dependency tree.

That recommendation makes sense if neither build tool is used.

But how many people in 2021 still seriously rely on versioned IDE-specific build configuration? You can always git add .classpath .project in the unlikely event you are creating a new Java project without a versioned build script which you intend to share with others who you know also use Eclipse and for which there will be no continuous integration. But you should not need to add these entries to every repository’s .gitignore when the normal case is that they are just junk. Using recommended global ignores, you should be able to

gh repo clone mycorp/some-random-maven-project
cd some-random-maven-project
code .
git status

and not see four untracked files IMHO.

(NetBeans has long made a point of opening directories with a pom.xml immediately as projects without an import phase and without writing any new files, but alas other IDEs have not followed suit yet.)

At any rate, I agree this PR should be considered as better than the status quo.

@baincd
Copy link
Contributor Author
baincd commented Sep 15, 2021

@jglick

These files [.factorypath and .settings/] are not generated based on the maven or gradle configuration.

Are you sure? I get e.g.

<factorypathentry kind="VARJAR" id="M2_REPO/javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar" enabled="true" runInBatchMode="false"/>

as a result of that JAR being defined in my dependency tree.

Good catch, I spoke too soon. But my original point is still valid - those files are already in /Global/Eclipse.gitignore, so there is no need to add them to the maven or gradle gitignore files also.

[The confusion is with .classpath and .project, which Eclipse's documentation confusingly recommends being under version control.] That recommendation makes sense if neither build tool is used.

But how many people in 2021 still seriously rely on versioned IDE-specific build configuration?

While I agree with you in theory, in reality these still exist in the wild (I worked on a few projects like this just a few years ago).

And as you can see earlier in this comment, those files have been added to Eclipse gitignore twice, only to be removed each time. There is clearly not a consensus this issue.

This PR was my attempt at a compromise that avoids all this debate, and would just work for all scenarios. But alas, it was rejected. :-/

@bdougie
Copy link
Contributor
bdougie commented Dec 6, 2021

This PR was my attempt at a compromise that avoids all this debate, and would just work for all scenarios. But alas, it was rejected. :-/

Feel free to reopen on a new PR linking to this one. This context was helpful to read and understand.

@baincd
Copy link
Contributor Author
baincd commented Dec 11, 2021

@bdougie,

This PR was my attempt at a compromise that avoids all this debate, and would just work for all scenarios. But alas, it was rejected. :-/

Feel free to reopen on a new PR linking to this one. This context was helpful to read and understand.

Opened #3920

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

0