Hi Scott,
Your points about .jmod are very valid, but I see this discussion somehow
separated from the original one.
There are plenty of developers using maven to compile, build and run JavaFX
applications. They need a maven-solution for those lifecycles.
Being pragmatic, I don't think native code in jar files is messy. There are
resources in jar files, meta-info etc.
Unless I'm missing something, we don't have a real alternative to address
the requests from the developers using maven?
Besides, I believe a split of generic code (Java) and platform specific
code (Java + native) is always a good thing, so I believe this is something
we have to do anyhow.
- Johan
On Fri, Sep 10, 2021 at 6:21 PM Scott Palmer <swpal...@gmail.com> wrote:
> I still think having .jmod files available from an artifact repository
> would be helpful. I’ve deployed them from the SDK to my local Artifactory
> repo for my own builds. Using Gradle I create a JRE with jlink if needed
> for running debug/tests during development, or I use an OpenJDK
> distribution that has bundled in JavaFX (like those available from Azul or
> BellSoft). The primary downside of using the .jmod files is that they
> can’t be used at runtimes o you need to build a JRE, but that is the
> recommended practice now for distributing applications anyway. I use
> jpackage for distribution so I'm bundling a JRE with the JavaFX modules.
>
> Using .jar files for libraries that contain native code is messy IMO.
> JMOD files are supposed to solve that - they should be the preferred way to
> include JavaFX in a build, but installing the JavaFX SDK is a pain when we
> use dependency management for everything else.
>
> Scott
>
> > On Sep 10, 2021, at 9:10 AM, Abhinay Agarwal <abhinay_agar...@live.com>
> wrote:
> >
> > JavaFX 17 Maven artifacts currently fail to compile modular JavaFX
> application. The non-modular application still works.
> >
> > To explain what's going on, let have a look at JavaFX and its Maven
> distribution since version 11:
> >
> > 1. JavaFX is distributed in non-platform (empty) and platform specific
> artifacts
> > 2. These artifacts along with the javafx plugins have helped developers
> to use JavaFX in platform agnostic way
> > 3. Platform jars have the `module-info.java` file, whereas,
> `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF.
> > 4. However, using `maven-jlink-plugin` with a JavaFX application fails
> since Automatic modules are not supported in JLink [1]
> > 5. After a brief discussion, it was decided to remove the Automatic
> Module Name from non-platform jars [2]
> >
> > The EA releases were working perfectly after the change was made.
> However, with recent JavaFX 17, modular applications are failing to compile
> with Maven.
> >
> > The reason behind this lies in the `plexus-java` library used by
> `maven-compiler-plugin`:
> >
> > 1. `plexus-java` doesn't allow duplicate entries with same module-name
> on module-path
> > 2. For 17, `plexus-java` resolves both empty and platform jar to have
> the same module-name
> > 3. However, with `-ea+xx`, `plexus-java` resolves the module name for
> empty jar as null and we never discovered the bug until 17 was released
> >
> > 17
> > ---
> >
> /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar
> > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor@c1c939a0
> > Module Name: javafx.controls
> >
> /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar
> > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor@31c3da0e
> > Module Name: javafx.controls
> >
> > 17-ea+18
> > --------
> >
> /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar
> > Module Name: null
> >
> /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar
> > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor@c896ba80
> > Module Name: javafx.controls
> >
> > ----X----
> >
> > This whole experience has made us realised we need to rethink how we
> package JavaFX Maven artifacts.
> > We are still discussing about the approach and naming, but we are
> throwing it out in the open to gather feedback:
> >
> > 1. Instead of 1 module per component, we will have 2 modules
> (javafx.base.api and javafx.base.platform)
> > 2. The `javafx.base.api`, unlike empty jar, will contain all generic
> Java code
> > 3. The `javafx.base.platform` will contain platform-specific native +
> Java code
> > 4. Current application declare their module-descriptor as:
> >
> > ```
> > module app {
> > requires javafx.base;
> > }
> > ```
> >
> > 5. In future this may be changed depending on how we end up wiring these
> modules together:
> >
> > ```
> > module app {
> > requires javafx.base [.api or .platform];
> > }
> > ```
> >
> >
> > [1] https://www.mail-archive.com/dev@maven.apache.org/msg123978.html
> > [2] https://bugs.openjdk.java.net/browse/JDK-8264998
>
>
