1

I have a Maven/Tycho project which is imported in Eclipse for editing and debugging, using the m2e Eclipse plugin.

The command-line Maven build works fine, but I have been struggling with spurious build errors in the Eclipse IDE which are apparently "fixed" by updating the Maven project (Maven > Update Project).

  • I have already excluded all .project and .classpath files from source control.
  • I have also ensured that all the necessary connectors for m2e are installed in Eclipse.
  • The spurious errors also vary with different versions of Eclipse, and this has gotten worse since the 2020-03 release.

I am suspecting that the errors are caused by files in the .settings being checked in, but apparently there are other settings beyond the Maven/Tycho scope in there which need to be preserved (editor preferences, etc.).

Is there a general rule or best practice as to which Eclipse-generated files should be checked in with a Maven project, if any?

mat101
  • 170
  • 1
  • 1
  • 11
  • 1
    Eclipse puts these files into the project folder and not into the `.metadata` folder, because you chose in _Project > Properties_ to have these settings as _project specifc settings_, so they are intended to be shared with others. This helps to avoid that different authors use different project specifc settings as long as they use Eclipse (otherwise, the settings are ignored). – howlger Apr 29 '20 at 13:23
  • Yes, and the fact that some projects have their own IDE, Maven-unrelated settings is something I would like to be able to achieve if possible But which settings files does the m2e need to generate? Are there any possible conflicts or race conditions? – mat101 Apr 29 '20 at 13:31
  • 1
    @howlger I cleared the duplicate, because that question is clearly discussing the antipattern of using the Eclipse-specific settings files as authoritative. For at least as long as m2e has been reliable, the best practice is to make the POM authoritative, as it's cross-IDE and the actual controlling mechanism for CLI (CI) builds. – chrylis -cautiouslyoptimistic- Apr 29 '20 at 13:36
  • To clarify my question, I would like to know which Eclipse settings files does m2e need to have control of, and if the .settings folder in a project should be in version control in the first place. – mat101 Apr 29 '20 at 13:42
  • You should ignore in VCS .. `.classpath`, `.project`, `.settings` and of course `target`(part Maven). You should never checkin IDE specific files...simple. Neither in Eclipse, IntelliJ IDEA or others... – khmarbaise Apr 29 '20 at 14:26
  • @chrylis-onstrike- The stuff in the `.settings` folder is not covered by Maven. Only the `.classpath` file can be derived from the `pom.xml`. It's like not to sharing a `Jenkinsfile` because there's is Maven. All tools agree on this (IDEs, GitHub, Jenkins, etc.). – howlger Apr 29 '20 at 14:38
  • @khmarbaise That's a common myth. The rule is that all project settings/configurations (which are unfortunately all tool-specific in Java) should be shared as long as they are maintained: FindBugs/SpotBugs, Eclipse `.settings` folder, `Jenkinsfile`, `pom.xml`/`build.gradle`, etc. – howlger Apr 29 '20 at 14:47
  • 1
    @mat101 No, there are no possible conflicts. For example, if you change the Java version in the `pom.xml` m2e just updates the files. But most of these project specific settings are not covered by Maven (project specific formatter settings, save actions, error and warnings, etc.). The worst case is that the settings are ignored because someone uses a too old Eclipse or a different IDE. It's like sharing a `Jenkinsfile` but someone else uses a different CI. – howlger Apr 29 '20 at 14:56
  • 1
    See https://stackoverflow.com/a/15942199/6505250 – howlger Apr 29 '20 at 14:57
  • 1
    @howlger That's not a common myth is practical experience. In particular if working in an environment where every dev is using a different IDEs/versions of them. And I know that `.settings` is not handled by Maven it's Eclipse. You have misunderstood my comment. `target` should be ignored as well cause it's done via Maven. A Jenkinsfile is very Specific to a CI solution (Jenkins) which you can share in a particular environment but if you are on GitHub it does not make sense to use a Jenkinsfile, but on the other hand GitHub Actions if you use them. – khmarbaise Apr 29 '20 at 15:08
  • I had to handle a large team of devs (ca. 100+) where it does not work to checkin specific tools configurations like Eclipse / IDEA IntelliJ (apart from different version) etc. only commonly used tools like Jenkins (Jenkinsfile only) make sense (for central build). Formatting rules only via Tool (for example checkstyle if you use Maven/Gradle) maybe you dev in Ruby/JS/Go/Rust ? – khmarbaise Apr 29 '20 at 15:10
  • @khmarbaise What doesn't work is to document such things or create a report via Maven/Gradle/whatever. You can make the CI build fail and send emails. But this is like 2000. Nowadays there are solutions that work and do not waste time. Consider to make use of them. – howlger Apr 29 '20 at 15:31
  • Can you explain of what reports you are talking about? or documentation? – khmarbaise Apr 29 '20 at 18:56
  • @khmarbaise You were talking about Checkstyle. But also ecj can be used as a linter to create an HTML report with the found problems in a build. The ecj settings are stored in the `.settings` folder and are read by Eclipse, VS Code and even IntelliJ can read them via its built-in ecj. In addition, _save actions_ automatically fix some problems before the code is shared which is better than having rules to follow manually, isn't it? Can you give a definition of _IDE specific files_ and of _commonly used_? Where do you want to have project specific configurations instead? – howlger Apr 30 '20 at 10:27
  • If you put it into `.settings` you can't run it in your build cause it's specific to Eclipse. Also configurations for IntelliJ the same things every rule should be checked by the build. It can be supported but not verified. The verification is done always by the build and fails if a check fails...simple rule that won't work with any IDE specific configuration... – khmarbaise Apr 30 '20 at 11:01
  • @khmarbaise You can run ecj in your build (to generate HTML reports, make the build fail or whatever). I did that already 15 years ago. – howlger Apr 30 '20 at 12:22

0 Answers0