Re: JavaFX 17 Maven Artifacts
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 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
> 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
>
>
Re: JavaFX 17 Maven Artifacts
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 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
Re: JavaFX 17 Maven Artifacts
Hi Abhinay,
The curios thing is that if the automatic module name is present all is working
fine at least with jdeps and therefore with moditect . A short fix would be to
bring the entry from 17ea+14 back into the manifest file until the your
described end solution will be implemented.
Cheers
Clemens
> On 10. Sep 2021, at 15:18, Abhinay Agarwal wrote:
>
>
> Hi Clemens,
>
> If you have any thoughts/suggestions, please let us know.
>
> -Abhinay
> From: clemens.lantha...@itarchitects.at
> Sent: Friday, September 10, 2021 6:46 PM
> To: Abhinay Agarwal
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: JavaFX 17 Maven Artifacts
>
> Thanks allot for the detailed explanation!
>
> Than I wait until a final solution will be available. My plan was to upgrade
> all projects after the jdk 17 release to the newest javafx version.
>
> > On 10. Sep 2021, at 15:11, Abhinay Agarwal 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
>
Re: JavaFX 17 Maven Artifacts
Hi Clemens,
If you have any thoughts/suggestions, please let us know.
-Abhinay
From: clemens.lantha...@itarchitects.at
Sent: Friday, September 10, 2021 6:46 PM
To: Abhinay Agarwal
Cc: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX 17 Maven Artifacts
Thanks allot for the detailed explanation!
Than I wait until a final solution will be available. My plan was to upgrade
all projects after the jdk 17 release to the newest javafx version.
> On 10. Sep 2021, at 15:11, Abhinay Agarwal 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
Re: JavaFX 17 Maven Artifacts
Thanks allot for the detailed explanation!
Than I wait until a final solution will be available. My plan was to upgrade
all projects after the jdk 17 release to the newest javafx version.
> On 10. Sep 2021, at 15:11, Abhinay Agarwal 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
JavaFX 17 Maven Artifacts
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
