On Mon, 8 Jul 2024 09:08:19 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
> I work around this by running the test once, then changing its configuration > and adding a standard incantation to its command line (`-Djavafx.toolkit`, > `-Djava.library.path`, some `--add-modules`) The `--add-modules` could be taken care of by the eclipse plugin. The other 2 are javafx specific. > fixing the problems in the gradle build so Buildship recognizes it properly. > Since I suspect the latter is not an easy task, removing the Gradle nature > seems like a good alternative. Yes, https://github.com/openjdk/jfx/pull/1232 should be part of the effort to simplify the gradle build file. It will take several iterations on that file to modernize OpenJFX's build. > so this is a non-standard setup, meaning it is not described in the > https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse > wiki page. Yes, it's not described in the wiki because it can't read the gradle file properly to begin with. > Still, I would like to propose we proceed with this change even if it is a > temporary one (until the Buildship plug-in gets mature enough to be able to > import the gradle configuration cleanly) because it prevents the said > Buildship from messing up the project files and breaking the build every time > the project(s) are imported or reopened. I'm fine with this. Just noting that we're not waiting on Buildship to catch up, we need our `build.gradle` to catch up :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2215516698
