Eclipse files in Git repos

Development
1

I’m wondering why .project and .classpath files are checked in to the repositories - or at least it is in core. Is there any advantage to this?

As far as I know, they depend on the Eclipse version and can contain references to local file paths or other “local” information. I’m used to them being in .gitignore, not in the repo.

When you use Eclipse, it keeps changing these files automatically at times, causing the files to be staged for the next commit. I constantly have to make sure not to include them, I’ve been using “skip worktree” - but new ones seem to pop up from time to time (they pop up if Eclipse has changed them).

So, I’m wondering if they really are there for a reason, or is just some leftover from the past that could be removed (from the repo - not deleted locally)?

2

See also VSC always change .classpath file of each bundle

3

Yes, that’s basically the exact same issue I’m raising. I think these files shouldn’t be in Git the repo at all, and added to the ignore list, so that local software can manage them as it see fit. There’s no way to get these to work well across different IDEs and versions of those anyway.

The question is only if anything woud “break” if they weren’t there, and more importantly: How we can determine/check if that’s the case.

4

I’ve spent 8 hours or so to get the dev environment to work again in Eclipse, and I’m starting to have a pretty good idea of what happened. This is unrelated to the topic of whether these files should be included in git, but it could be useful for others to be aware of.

I use VSCode for things like HTML, JavaScript, the odd Python and similar things. I don’t consider it a proper IDE, it’s more like an “advanced text editor plus”. But it’s fine for languages where I don’t have a dedicated IDE.

I was a bit frustrated with the GitHub review process and the fact that it’s often so hard to find the code comments (not all appear on the “PR page”, so you just have to scroll through all the changes, and hope that you spot them (some are collapsed)). So, I figured out that you can do reviews from VSCode as well, and as far as I could understand, there’s a key binding to “jump to the prev/next comment”. That sounds like a dream, so I figured I’d give it a go and installed the extension. I then saw that you could only access PRs in the Git repo that was in the “open folder” in VSCode, so I “opened” the root folder of the core repo in VSCode. Never again!

What happened next is that VSCode started “preparing” and whatnot, and essentially crawled almost to a halt. The same with Eclipse, it started building and refreshing constantly. I realized that this smelled like disaster and closed the folder again in VSCode. I’m always afraid of messing up the Eclipse setup because it is so brilliant when it works, but can take hours and hours of frustration when it won’t work. But Eclipse was still going with whatever this had started. I quit VSCode completely, but that made no difference.

I then started doing the things I’ve experienced that usually is needed when Eclipse is acting up - “Update Maven project” for select bundles, rebuilding some from Maven, opening and closing projects and whatnot. I restarted Eclipse completely several times, closing down more and more stuff, but the same thing happened. It wouldn’t really say what it was doing except some generic “preparing index”, “building” and similar, and the progress would either stay at 0% or increase a little bit and then get stuck.

None of “my usual tricks” were working, and I was losing hope that I would be able to get it to work again. I noticed that some .project and .classpath files had been changed (but that happens sometimes because Eclipse does so). But, after much frustration, I looked more closely into that. Since I don’t want these files to be committed, I mark them with “skip worktree” so that Git ignores them despite them being in the repo. So, I opted to “unhide” all files that were hidden by “skip worktree”, and that was when the full consequence was revealed. VSCode had apparently modified a lot (probably would have modified all if it had enough time) of these files, most of which were “invisible” to me since they were marked “skip worktree”. And, somehow these changes made Eclipse go completely crazy. Eclipse was unable to resolve it after chewing on this for hours, after rebuilding core entirely, updating and refreshing everything etc.

I quit Eclipse, and then used Git to revert all these modified files. Once that was done, I started Eclipse, it built like it does, but when it was done, it was actually working again (and this time the progress actually moved).

I found this description online:

Eclipse Compatibility: The VS Code Java extensions use technology from the Eclipse JDT Language Server. To manage project configurations (like source paths, libraries, and settings), the extensions use standard Eclipse metadata files, including .project and .classpath.

To translate, what it actually does is corrupt these files in such a way that Eclipse is unable to work. All the changes VSCode does must be reverted to get things up and playing again, and this is done “without your consent” simply by opening the “folder” with the Git repo in VSCode. This is actually a very bad thing to do, and people need to be aware of this. I think the VS Code Java extension is “dangerous” to have installed. If I couldn’t use Git to revert them, I would probably have had to delete them all (it’s too much work to figure out what was “wrong” and how to fix that manually in all these files), and import every bundle again. I still lost all the settings I have made for individual bundles, but it could have been worse.

Extremely bad behavior by the VS Code Java extension.

5

IIRC they were not removed from openhab-core because without these files there were build issues after importing the projects with the Eclipse installer. I think they also contain some config for the Eclipse xtext/xtend plugin to work correctly.

Maybe you can also create a PR with the changes in the files so development is less annoying?

6

The point is that I don’t think there exists a “correct” content for these - I think it depends on the IDE you’re using, and the version.

Eclipse keeps replacing the .classpath files every time I build, the .project files are changed much more rarely, I think it’s only if I change some properties of the project/bundle - like ignoring certain type of nullness annotation error, which I must do to make some bundles build.

Maybe it would be possible to at least reduce the number of these files significantly, maybe only a few are needed for the xtext/xtend stuff for example. It would help greatly if it only applied to those bundles, but the big question is how to figure out at which point it “breaks”.

I could create a branch where I remove them all and setup Eclipse “from scratch” using the Eclipse installer and see what happens I guess, but it’s a bit of a shot in the dark. Do you, or anyone else, remember anything of where the problem was originally discussed - maybe there’s more info to be acquired by reading that?

7

I found back the discussion I remembered after some archeological research:

1 Like
8

I found this:

…which is “borderline off-topic”, but sounds like it should be related to the mess VSCode makes. However, as I understand this, it should default to not modifying the files, which is not what I’ve experienced. I certainly haven’t modified this setting, I don’t use VSCode for Java, so this is just setup as default when VSCode installs extensions.

9

As far as I can understand, it boils down to this:

Well, as all of you seem to be clear on it, I hardly stand a chance to argue against it as it seems.
Import as Maven project seems to work ok by now, so that seems indeed a standard way to use then.
Only downside is that we have different approaches for core+distro and add-ons then, because for the proper IDE setup, I hope we keep core+distro the way they are - unless someone manages to change the Oomph setup to smoothly import those projects as Maven projects.

So, the reason they were removed from addons is that all the add-ons are no longer imported during automatic setup by Oomph, which isn’t the case for distro and core - and this explains the difference. I guess I’d have to experiment with the Oomph setup to see if there’s a way to get it to import without them. It’s a bit strange that it can’t use the same import functionality that is used when you import “manually” (existing Maven project), but the devil is in the details I guess.

10

Might be worth a try to see if it is still an issue after years of bugfixes and improvements.

1 Like