Thanks, that worked perfect. ea-24 is available now. - Johan
On Wed, Aug 22, 2018 at 3:03 PM Lennart Börjeson <lenbo...@gmail.com> wrote: > 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) 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 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 > > 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> > 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 >> >> >> >
