Why do people gitignore .classpath and .project?

Question

One of my colleague recently created a new project in eclipse ,committed and pushed with built-in git client. After I cloned to my computer and opened with eclipse, I found eclipse creating .classpath file. Isn't .classpath a crucial file for eclipse project(also .project) to find referenced jars? I am very confused after googling, seeing all the discussions talking about ignoring them. Aren't they crucial to Eclipse to work correct ? Why are people ignoring them ? What's the problem if I have them not ignored ?

Answer 1

These Eclipse-specific files make it easier to set up Eclipse and Visual Studio Code for a Java project.

In general, IDE and tool specific files (Eclipse, Jenkinsfile, GitHub workflows settings, etc.) should be shared as long as they are used and maintained. Otherwise, delete them.

Of course, if you use a different IDE than Eclipse and Visual Studio Code and do not use the Eclipse compiler in IntelliJ IDEA, these Eclipse-specific files are useless, but they do no harm. As long as you do not use functions like file or folder links (stored in the .project file), sharing these files does not lead to IDE lock-in.

In Maven and Gradle projects the .classpath file can be derived from the pom.xml or build.gradle file, but settings that cannot be derived like compiler settings (warnings and errors), formatter or save actions settings (which are stored in the project's .settings folder) should be shared so that everyone uses the same.

This also applies to the .project file, as it contains which natures the project has and which tooling is required. If something is missing, a dialog will ask if the missing plug-ins should be installed.

Eclipse puts these files into the project folder and not into the .metadata folder, because they are intended to be shared. But why there are people who do not share these files? Probably because of historical reasons. 15 or 20 years ago, there wasn't Git, Maven and Jenkins. In these days, a Java application was usually built on a developer's computer by manually exporting JARs or at best via some batch/shell scripts. This meant, making the same build on a different computer or even just with a different IDE or IDE version might led to a different result, causing a lot of trouble. IDE agnostic builds was the solution for this problem. Maybe that's why people today still think that everything have to be IDE agnostic and recommend to use Maven or Gradle. But these files are not shared to build a product to be shipped. Hopefully.

Answer 2

They're Eclipse specific, so they don't really belong to the project's source code. Developers might be using different IDEs, so Eclipse's .classpath would be useless for someone using IntelliJ IDEA for example.

Since the project most likely uses Maven / Gradle / some other build system, the IDE is capable of generating the classpath based on the pom.xml or build.gradle files, as you noticed. Only if there isn't a build system, and the project is IDE specific, it would be necessary to include those files to make sure the project keeps its meta-data. But that's an unlikely scenario in modern times and real life work situations.

It doesn't usually cause problems to include those (unless there are conflicting project specific configurations from different developers), but they're not necessary either. I don't include them since there's no advantage, and it keeps the root of the project cleaner.