On Wed, 26 Jun 2024 21:23:34 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
> This might be controversial. I am proposing to remove the Gradle integration > in the Eclipse config files. > > Problem > ======= > Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle > cleanly. Every time the project is imported into a new workspace (or > re-opened after being closed) it executes Gradle, creates and modifies a > number of Eclipse .project and .classpath files, all of which need to be > reverted for Eclipse workspace to become usable again. > > Solution > ====== > Remove Gradle nature from the Eclipse project files. This change only affects > Eclipse config files and does not impact build.gradle or other IDEs. > > Advantages > ========= > 1. The multiple nested projects in the repo will get imported cleanly on the > first attempt, will not require additional steps to clear the Buildship > changes. > 2. completely removes the dependency on the Eclipse Buildship and its > idiosyncrasies. > > NOTES: > - even though the reverse was done for IntelliJ, but its gradle import still > does not import tests cleanly, see > [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) > - this improvement contradicts > [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse > files in the repo, it will be impossible to use Eclipse in a meaningful way > without the fully functional Buildship support, and that is a big IF. > - once integrated, Eclipse users would only need to re-import the main > project with 'search for nested projects' enabled Continuing the [mailing list](https://mail.openjdk.org/pipermail/openjfx-dev/2024-June/047467.html) discussion with more technical details. Gradle tries to configure Eclipse based on its build file. This includes things like source folders, compiler settings, dependencies and others. In the cases that I have tried in my projects, this works well. One problem that still remains with this configuration is that it's not aware of the locations of the modules. This causes missing module errors when launching, which require `-add-modules` to remedy. The [eclipse plugin](https://docs.gradle.org/current/userguide/eclipse_plugin.html) solves this by resolving the paths locally for your gradle cache. This tends to be the preferred way to do things from my experience since you don't need to push eclipse-specific files to the repo. The gradle files need to be there anyway, so it makes sense to configure eclipse from them and you maintain uniformity between the different development environments. Where this fails is with OpenJFX projects. The monolithic and old gradle file uses conventions from old gradle versions. This causes faulty generation of the eclipse files with and without the eclipse plugin. For example, all the source folders (`src/main/java`, `src/test/java`...) are prepended with the project/module name (`base/src/main/java`) because of manual source set configurations that shouldn't exist, at least not the way they are now. The problem presented in the issue has 2 solutions: 1. Opt out: Include the Gralde nature by default, do all the initial building, then revert the Eclipse files. If you want to disable the Gradle integration, you can do so as well be removing the nature within the IDE. 2. Opt in: Don't include the Gradle nature by default and do all the initial building. If you want the Gradle integration, you can add it within the IDE. Both of these are one-time actions. I'm fine with either since I find the one-time action to be cheap. By the way, with this change you will also have to update the [wiki page](https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse) to a state where the Java import is the standard and there's an opt-in for the Gradle integration. @hjohn Do you have any remarks? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2212068694
