JavaFX 11 snapshots in maven sonatype

Fri Jul 6 17:15:04 UTC 2018

Hi Johan,
many thanks for the clarifications.
Please find some more comments inline:

Am 06.07.18 um 14:54 schrieb Johan Vos:
> 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
I can confirm that this works as you said if the property is specified 
on the command line
but I am wondering why this does not work if you
set javafx.platform inside the pom.xml as a property like this

or if you specify the classifier explicitly.

     <classifier>mac</classifier>

or if you specify the property in the Maven settings.xml file.

In all these three cases Maven still downloads everything.
>
> 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)
This looks good to me but shouldn't we then use this architecture 
extension right from the beginning in order to avoid future confusion?
>
> For Eclipse: by setting the {javafx.platform} variable somewhere, it 
> will be avoided to download the other platforms.
What would be the right place to do that? As pointed out above the right 
place seems to be very sensitive.
> 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.
>
I was able to temporarily fix this by introducing a separate launcher class.

     package org.projavafx.javafx3d.hello3d;
     public class ShapesLauncher {
         public static void main(String[] args) {
             Shapes.main(args);
         }
     }

But this is a terrible hack.
> 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
>     }
> }
>
I doubt that this will help to set up the class/module path correctly 
when you import an external project into Eclipse.
> (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).
That is absolutely true and to my opinion we are not doing ourselves a 
favor if we force people into using modules if the most common build 
tools are still not able to fully handle the module system in a 
consistent and correct manner.
> 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?)
How long are we going to wait for this to happen? My impression is that 
there still is not enough pressure on the tool providers because the 
majority of people is still on Java 8 (or less) and are just ignoring 
the new module system.
>
> - Johan
>
>
> On Fri, Jul 6, 2018 at 12:51 PM Michael Paus <mp at jugs.org 
> <mailto:mp at 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
>
>