Hi Michael, Thanks for testing this.
You can avoid downloading all platform jars by specifying the javafx.platform with maven: mvn -Djavafx.platform=mac clean package exec:java There is a rationale behind this: maven would be able to detect the OS and make sure only the platform jars related to that OS are downloaded. But that won't work with gradle. So we have this base pom that, unless javafx.platform is specified, will depend on all platforms, which will cause gradle to download the correct platform (and the others as well). Now, for SNAPSHOTs this doesn't work with gradle (see previous mail) but that is another issue. For releases, this works with gradle. I'm very open to suggestions on how to change this. As for architectures: I would suggest we follow the approach of the excellent nd4j project and append the arch if used (see https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/ -- it even includes linux-x86_64-avx512) For Eclipse: by setting the {javafx.platform} variable somewhere, it will be avoided to download the other platforms. But your error message seems to suggest something else: Error: JavaFX runtime components are missing, and are required to run this application That is an issue I brought up somewhere else: http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021977.html The Java launcher will check if the main class extends javafx.application.Application and if that is the case, it will do a hard check on the availability of the javafx.graphics module in the modulepath. If it can't find that, it will bail with the message above. So that is happening. This doesn't happen when you launch via maven, as maven is launching the application inside its own Java process -- hence the main class is a maven class, not extending javafx.application.Application. The solution to this is somehow tell maven or eclipse to use modules. With gradle, we have a relative easy way to do this: run { doFirst { jvmArgs = [ '--module-path', classpath.asPath, '--add-modules', 'javafx.controls' ] classpath = sourceSets.main.output } } (unfortunately, we can't use gradle due to that snapshot/platform issue, but I tested it with a release extension instead of a snapshot extension and then it works). I would assume maven allows for a similar approach. In general, this is an issue not specific to JavaFX: how can you tell maven to use the artifacts as modules (e.g. set the correct module-path and add the modules). The only thing that is JavaFX specific is that the Java launcher will exit if ((the main class extends Application) AND (no modules used)). See http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021983.html for the discussion about this. I'm not 100% what the best approach is here. It sounds a bit unfair that you can only NOT use classpath when your main class extends javafx.application.Application, but the best approach is probably a fix in a maven plugin so that it works with modules (might already be there?) - Johan On Fri, Jul 6, 2018 at 12:51 PM Michael Paus <m...@jugs.org> wrote: > Hi, > I tried the examples on my Mac with Maven and with a simple > mvn clean package exec:java > on the command line they all compiled and worked out of the box. > Great work! I used OpenJDK 11ea20 for this. > > I have a few questions though: > > 1. I observed that maven downloaded all dependencies for all platforms > (mac,win,linux) > which does not seem to make much sense. Is this normal or could that be > prevented somehow? > > 2. How would the platform concept be extended once we have to also > distinguish between architectures? > (Linux on x86 vs. Linux on ARM for the Raspi for example) > > 3. How is this setup supposed to be used in an IDE like Eclipse. I tried > to import one of the example projects > into Eclipse and Eclipse ended up creating maven dependencies for all > platforms and not just the Mac. > This has the consequence that you cannot start an example directly in > Eclipse anymore because it then fails with: > Error: JavaFX runtime components are missing, and are required to > run this application > You can launch it via maven but I normally prefer to do it directly > which is no problem with a normal maven project. > > Michael > > Am 05.07.18 um 11:03 schrieb Johan Vos: > > A first batch of snapshots for the JavaFX 11 modules is now in the maven > > sonatype snapshot repository (see > > https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/ > although > > you probably don't want to work with these artifacts directly but use > build > > tools like maven or gradle to do that) > > > > This is work based on the not-yet-merged PR#83: > > https://github.com/javafxports/openjdk-jfx/pull/83 > > > > Basically, you need to specify which modules you need (transitive > > dependency management will be handled by maven as the modules contain a > > pom.xml with the same dependencies as the module-info.java), e.g. > > > > > > <dependency> > > <groupId>org.openjfx</groupId> > > <artifactId>javafx.controls</artifactId> > > <version>11.0.0-SNAPSHOT</version> > > </dependency> > > > > > > I have a few samples that show how you can use those artifacts in your > > maven project: > > https://github.com/johanvos/javafx11samples (note that this is a > temporary > > repository) > > the topics/javafx3d directory contains a number of standalone samples > that > > can be executed via > > mvn clean install exec:java > > > > Note that some of the samples create a build.gradle as well, but I never > > managed to get gradle working with the combination of classifiers and > > SNAPSHOT versions (it's actually the reason why I went back from gradle > to > > maven in other projects -- e.g. dl4j related). > > > > If someone else can somehow fix the build.gradle, that would be great of > > course. > > > > Before PR#83 is merged, it would be nice to have a few reports from > people > > using the snapshots. > > > > - Johan > > >
