Sound reasonable, thank you. In the meantime (waiting for the next version of the maven artefacts) I've updated my PR (https://github.com/johanvos/javafx11samples/pull/1 <https://github.com/johanvos/javafx11samples/pull/1>) for your javafx11samples with a build.gradle work-around to filter out the empty javafx-jars.
This makes your samples run with Java 11, gradle 4.9 and openjdx 11-ea+19. /Lennart > 22 aug. 2018 kl. 14:11 skrev Johan Vos <johan....@gluonhq.com>: > > I spent some more time on this. > Adding the Automatic-Module-Name seems the easiest fix to me. I created a PR > at https://github.com/javafxports/openjdk-jfx/pull/162 > <https://github.com/javafxports/openjdk-jfx/pull/162> for this. > > Having the platform-name hardcoded in the artifact Id would require upfront > magic in build.gradle or pom.xml to prevent the need to put a platform > hardcoded in the build.gradle or pom.xml. > Removing the empty jars never gives a result that works fine for both maven > and gradle, see > https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 > <https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804> > > In the end, the real fix for this should be in maven/gradle. We currently > need to specify dependencies in both the module-info.java as well as in the > pom.xml. That doesn't sound right. I would assume that the gradle Java plugin > should check if a dependency contains a module-info.class, and if so, parse > it and process it. > > - Johan > > > > On Thu, Aug 16, 2018 at 11:26 AM Lennart Börjeson <lenbo...@gmail.com > <mailto:lenbo...@gmail.com>> wrote: > FWIW, I've fixed the Gradle builds in the current javafx11samples and sent > you a pull request. > > I know these samples are only temporary, but I believe I'm not the only > gradle user who's been frustrated by not having any working example to try > out. > > My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in the > dependencies using Gradle's OPeratingSystem class. > > > > Best regards, > > /Lennart > >
