7

I have a multi-module Maven Java (WAR) project in Eclipse. It depends on a bunch of other Java projects. We check our .settings directory into source control because there are many manually established settings in there.

One of the files in .settings is org.eclipse.wst.common.component which also has manually established settings. However, Eclipse is constantly modifying that file based on which underlying JAR projects the developer has open in Eclipse. I believe it does this to help accomplished "workspace resolution" of those artifacts.

However, the result of this situation is that Eclipse is constantly modifying that org.eclipse.wst.common.component and developers are constantly committing it to source control and fighting over it with one another. Leaving those files out of source control does not work as there are too many manual tweaks in there that are specific to each project.

I am guessing that it is a design flaw in Eclipse to have a file that combines project settings and users settings together! If anyone has any insight into how to better handle this problem that would be great. As it is, Eclipse-M2E is simply not working for team development on complex projects unless every developer has EXACTLY the same Java projects loaded....

Dave
  • 21,524
  • 28
  • 141
  • 221
  • I've just discovered this problem in my own workspace. What did you end up doing to resolve? Have you used IntelliJ with this Maven project before? If so, how is it? – Daniel Aug 25 '17 at 22:42
  • 3
    I know this is going to sound ridiculous, or like an exaggeration, or like a paid advertisement. But this was the issue that broke the camel's back... after this I was finally forced to let the team tryout Intellij. I'm not saying it's without flaws, but it is so much better than Eclipse, I really regret having not switched years ago. A huge blunder on my part. – Dave Aug 25 '17 at 23:38
  • 1
    For the most part, IntelliJ has a fairly clean separation between workspace files and project files so that things like this do not happen. Again, it's not perfect but it's ten times better. – Dave Aug 25 '17 at 23:39

1 Answers1

1

I agree that that particular file is problematic... If it gets corrupted, the workspace will probably crash, and if it's missing - nothing will work. But it contains nothing that can't be generated from scratch when re-importing a project...

I think the best solution is to check in the file using the "full" workspace, and then make sure that future changes are ignored.

If you then need to do a "real" change, load the full workspace, do whatever you need to do, and then un-ignore the file, check in, and then ignore it again.

ex:

git update-index --assume-unchanged the-file
git update-index --no-assume-unchanged the-file

With some luck, m2e will mess around with the jar/project references so it matches the loaded projects. If it doesn't do it automatically, update the project definition.

Community
  • 1
  • 1
KarlP
  • 5,149
  • 2
  • 28
  • 41