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
<properties>
<javafx.platform>mac</javafx.platform>
...
</properties>
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 <m...@jugs.org
<mailto: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
