5

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 ?

Kayaman
  • 72,141
  • 5
  • 83
  • 121
HarryTheF
  • 299
  • 1
  • 4
  • 11
  • 8
    Some people (including me) want to keep their codebases "IDE-agnostic", so that it's up to the developers to choose the tool they want. Say three developers use three different IDEs, the codebase would be polluted with all those IDE-specific configuration files otherwise. – sp00m Mar 13 '20 at 10:08
  • 3
    You commit your Eclipse files, I commit my IntelliJ files, the guy next to me his NetBeans files and another guy his VSCode files. Result: unholy mess. And then we're not even getting into conflicting settings files for the same IDE... – Robby Cornelissen Mar 13 '20 at 10:09
  • 3
    I upgrade Eclipse, and you don't. I commit my `.project` file, now your environment is broken. We should be using maven to manage our classpath. – Elliott Frisch Mar 13 '20 at 10:10
  • @ElliottFrisch Committing the `.project` file does not break the environment of the others, independent which Eclipse version they have. – howlger Mar 14 '20 at 00:26
  • @howlger Are you sure? Because I've experienced it. And the fix was to delete the `.project` file and regenerate it (and then add `.project` to ignore). – Elliott Frisch Mar 14 '20 at 00:29
  • 1
    @RobbyCornelissen Well, the Eclipse files and VSCode files are the same. So in your example, two will benefit from each other by sharing these files. – howlger Mar 14 '20 at 00:43
  • @howlger How are they the same? Eclipse doesn't generate a .vscode directory. And I doubt that VSCode will generate Eclipse configuration files. – Robby Cornelissen Mar 14 '20 at 01:08
  • @RobbyCornelissen Read [my answer below](https://stackoverflow.com/a/60669809/6505250) or create a Java project in VSCode and look into the files that have been created. Please also note that your _"unholy mess"_ is hidden (starting with `.`) for reasons. – howlger Mar 14 '20 at 07:55
  • @ElliottFrisch You may have experienced an invalid XML of the `.project` file due to merging, but what you are saying is impossible since the `.project` file contains nothing version specific. – howlger Mar 14 '20 at 08:11
  • @howlger You did put up a far better defense of your preferred way of working than I expected, so +1. For my workflow, I prefer to keep non-source code out of the project. For the examples you list, compiler settings go into our `pom.xml` files, and formatting/style settings go into a separate repo (centrally managed and used across all projects by the entire team). Required tooling for what Eclipse calls "natures" is automatically derived by IntelliJ. To each his own I guess. – Robby Cornelissen Mar 14 '20 at 08:17
  • @RobbyCornelissen The Eclipse compiler settings cover more than what you could put in a `pom.xml` file and Maven does not work for everything (for example, a Maven repository cannot be used to resolve OSGi dependencies). Eclipse can also automatically detect projects natures and configure the project accordingly. It is like in Java, not everywhere `var` makes sense. If you have common settings in a separate repo, you may want to be warned if the reference to that repo cannot be resolved. – howlger Mar 14 '20 at 08:52

3 Answers3

10

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.

howlger
  • 31,050
  • 11
  • 59
  • 99
  • To be honest, build tools, version control and even continuous integration (although that was still in its infancy for most development) existed 20 years ago. What didn't exist was a wide array of quality IDEs or large amounts of open source code, so everyone in the company would be working with standard tools (probably WSAD). – Kayaman Mar 16 '20 at 13:45
  • 1
    That reminds me of my own answer 10 years ago: https://stackoverflow.com/a/2819639/6309 – VonC Apr 02 '20 at 17:41
  • @Kayaman At that time products were often built by a developer making an export in the IDE, even though CI already existed (for example, I used CruiseControl in those days). If this did not result in a reproducible build, the IDE was blamed for it, even if, for example, it was caused by a non atomic commit of CVS (which cannot happen with Git). – howlger Apr 05 '20 at 15:58
  • @VonC Yeah, without _"Why there are people who do not share these files"_ it would be a duplicate. +1 for your great answer that long ago (more people should have read it). – howlger Apr 05 '20 at 15:58
3

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.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • There is more than dependencies. IMHO it is an advantage if everyone follows the same coding conventions. Eclipse puts them there because they are intended to be shared (otherwise Eclipse would store them in the `.metadata` folder). – howlger Mar 13 '20 at 12:23
  • @howlger I would try to avoid project specific coding conventions, at least for languages like Java that have a well defined convention "built in". Linting should be done by a separate tool in the build process anyway, not by the IDE, so warning/error settings don't need to be shared through IDE-specific files. But in the big scheme of things it doesn't make much difference, commit them or don't commit them, it won't cause irreparable harm. – Kayaman Mar 13 '20 at 13:56
  • [The last revision of the Java coding convention was made more than 20 years ago](https://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html) and the Eclipse compiler can also be used as linter in a build. But this is not the point. Better do things automatically than error-prone and time-consuming manually. Unfortunately, not all of these can be done in a Maven, Gradle, or whatever build. Not sharing the settings files harms those who use these tools for automation. – howlger Mar 14 '20 at 00:16
  • @howlger my point exactly, the Java coding convention was perfected when I started writing Java, so there's no need to have per project conventions as there's a single standard. As for your other argument, the IDE **can** be used as a build tool, a linter, etc. but **should not**, which is why we have maven, findbugs, etc. tools, which have IDE support allowing us to commit the tool specific, IDE agnostic config files instead of the IDE specific config files. I'm not claiming things should be done manually, I just know they can be done automatically without committing `.project`. – Kayaman Mar 14 '20 at 09:43
  • 1
    I disagree to use other tools in the IDE as in the build. The Eclipse compiler (which is contained in the Eclipse IDE and in IntelliJ) can and is also used by many like findbugs: to report problems in the IDE as well as in the build. I thought at first that a Jenkinsfile or a GitHub workflow file didn't belong in the project for the same CI agnostic reasons you mentioned to IDE agnostic. In fact, they have often helped me, even if I used a similar tool. The Java specification covers much less than newer languages do. Even Maven used by many is far from being a Java de facto standard. – howlger Mar 14 '20 at 11:02
  • 1
    @howlger well I disagree with you. I won't accept your Eclipse configuration files, I'm using IDEA. That's an entirely different thing than Jenkinsfile. Stop confusing the question by bringing **unrelated** things into it. Eclipse's `.project` is not the same thing as a Github workflow file, so don't compare them as if they were the same. And this question is about Java, not other languages, see tags. – Kayaman Mar 14 '20 at 14:05
  • 1
    The question is about a person who uses Eclipse getting a project created by someone else also using Eclipse. Your argument is not to accept configuration files from tools you don't use yourself. To me that sounds unreasonable, regardless of whether it is about IDE, CI, build or whatever. IMHO tool-specific project settings should be shared as long as they are used and maintained. Please note, the question is tagged with Java and Eclipse. – howlger Mar 14 '20 at 15:17
2

That very much depends.

If your team decides that the eclipse project configuration files are the essential source of truth, and everybody else should be using them: then sure, these files should sit in your source code management repository.

But doing so leads to "IDE lock-in". Or worse, it leads to having multiple files containing the same information, as a future IntelliJ user might prefer to add .iml files on top of that. So any change to project definitions needs to happen twice now.

So, ideally, in 2020: use other tools as your base source of truth (like gradle definitions), and then tell your individual IDE to use that.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • What other tools are you talking about that can handle things like warnings/errors, formatting or save actions? How else can it be achieved that everyone follows the same coding conventions? What about `Jenkinsfile`, GitHub workflows, etc. settings? – howlger Mar 13 '20 at 13:06
  • 2
    There is no IDE lock-in. The only source of truth must be the integration build (e.g. pull requests on Jenkins or whatever you use), and that is totally independent of any IDE settings. Using gradle as central configuration is nice, agreed. However, it can only configure a tiny amount of all the available IDE settings, therefore it generally doesn't help. I've worked in gradle based projects, and devs continued to need both the IntelliJ and Eclipse settings checked in on top of that. – Bananeweizen Mar 14 '20 at 14:05