Discussion:
State of maven artifacts
Nir Lisker
2018-09-25 21:17:31 UTC
Permalink
Hi,

I haven't kept up with all of the Maven artifacts discussion. The website
mentioned in 2 places that there are maven artifacts, but does not mention
their ID's, group etc. These are the downloads page [1] and the getting
started page [2] (later you can see an example pom, but that doesn't count).

I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it finds
the artifacts. It should be written in the above pages if this is correct.

On the usability side it's worse. I'm using Eclipse and during compilation
I'm getting error messages that JavaFX classes like BooleanProperty can't
be found. Is it a JavaFX problem, Eclipse problem, or me problem?

If I use the SDKs, can I point Gradle and Maven to them if it will solve
the problem?

- Nir

[1] https://gluonhq.com/products/javafx/
[2] https://openjfx.io/openjfx-docs/#introduction
Sam Carlberg
2018-09-25 23:37:35 UTC
Permalink
The libraries are in artifacts with platform-specific classifiers. The
artifacts with no classifiers that you currently depend on are completely
empty.

You need to depend on "org.openjfx:javafx-base:11:$platform", where the
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The website
mentioned in 2 places that there are maven artifacts, but does not mention
their ID's, group etc. These are the downloads page [1] and the getting
started page [2] (later you can see an example pom, but that doesn't count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it finds
the artifacts. It should be written in the above pages if this is correct.
On the usability side it's worse. I'm using Eclipse and during compilation
I'm getting error messages that JavaFX classes like BooleanProperty can't
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it will solve
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/
[2] https://openjfx.io/openjfx-docs/#introduction
Nir Lisker
2018-09-26 03:45:27 UTC
Permalink
Thanks Sam, that solved it. For some reason I was thinking that if you
don't specify the platform it downloads a version with all native
dependencies for cross compilation.
Post by Sam Carlberg
The libraries are in artifacts with platform-specific classifiers. The
artifacts with no classifiers that you currently depend on are completely
empty.
You need to depend on "org.openjfx:javafx-base:11:$platform", where the
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The website
mentioned in 2 places that there are maven artifacts, but does not mention
their ID's, group etc. These are the downloads page [1] and the getting
started page [2] (later you can see an example pom, but that doesn't count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it finds
the artifacts. It should be written in the above pages if this is correct.
On the usability side it's worse. I'm using Eclipse and during compilation
I'm getting error messages that JavaFX classes like BooleanProperty can't
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it will solve
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/
[2] https://openjfx.io/openjfx-docs/#introduction
Johan Vos
2018-09-26 07:30:55 UTC
Permalink
The problem with that is that there is no cross-platform version of the
jars itself. The windows-jar for the graphics module contains different
Java classes than the linux jar, for example.
The top-level API's are the same of course, hence the logical Java module
is the same, but different physical jars are really needed.
I realise this may be strange at compile time, where you only care about
the top-level API's. Therefore, people added nice "tricks" to both a
pom.xml and build.gradle system to automatically detect the current (host)
operating system, and making sure the correct artifacts are then used.

What I really wanted to avoid is that developers had to manually add their
platform (e.g. "win") in the build files, as this would break
cross-platform development (imagine you're in a team with a win and a linux
user, and they constantly change the pom.xml or build.gradle file for
this...).

I think the current solution deals pretty well with the current situations,
where there are different concepts in gradle/maven/sonatype and in the Java
module system.

- Johan
Post by Nir Lisker
Thanks Sam, that solved it. For some reason I was thinking that if you
don't specify the platform it downloads a version with all native
dependencies for cross compilation.
Post by Sam Carlberg
The libraries are in artifacts with platform-specific classifiers. The
artifacts with no classifiers that you currently depend on are completely
empty.
You need to depend on "org.openjfx:javafx-base:11:$platform", where the
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The
website
Post by Sam Carlberg
Post by Nir Lisker
mentioned in 2 places that there are maven artifacts, but does not
mention
Post by Sam Carlberg
Post by Nir Lisker
their ID's, group etc. These are the downloads page [1] and the getting
started page [2] (later you can see an example pom, but that doesn't count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it finds
the artifacts. It should be written in the above pages if this is
correct.
Post by Sam Carlberg
Post by Nir Lisker
On the usability side it's worse. I'm using Eclipse and during
compilation
Post by Sam Carlberg
Post by Nir Lisker
I'm getting error messages that JavaFX classes like BooleanProperty
can't
Post by Sam Carlberg
Post by Nir Lisker
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it will solve
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/
[2] https://openjfx.io/openjfx-docs/#introduction
Michael Ennen
2018-09-26 10:19:03 UTC
Permalink
And just to reiterate and confirm for anyone trying to get a handle on using
the Maven artifacts - it is *NOT* necessary to manually specify the platform
classifier when using maven or gradle (nor add the automatic tricks to your
own project) because the JavaFX artifacts will automatically detect the
platform you are building on and pull in the correct artifacts, right?

Thanks for your work in this area Johan.
Post by Johan Vos
The problem with that is that there is no cross-platform version of the
jars itself. The windows-jar for the graphics module contains different
Java classes than the linux jar, for example.
The top-level API's are the same of course, hence the logical Java module
is the same, but different physical jars are really needed.
I realise this may be strange at compile time, where you only care about
the top-level API's. Therefore, people added nice "tricks" to both a
pom.xml and build.gradle system to automatically detect the current (host)
operating system, and making sure the correct artifacts are then used.
What I really wanted to avoid is that developers had to manually add their
platform (e.g. "win") in the build files, as this would break
cross-platform development (imagine you're in a team with a win and a linux
user, and they constantly change the pom.xml or build.gradle file for
this...).
I think the current solution deals pretty well with the current situations,
where there are different concepts in gradle/maven/sonatype and in the Java
module system.
- Johan
Post by Nir Lisker
Thanks Sam, that solved it. For some reason I was thinking that if you
don't specify the platform it downloads a version with all native
dependencies for cross compilation.
Post by Sam Carlberg
The libraries are in artifacts with platform-specific classifiers. The
artifacts with no classifiers that you currently depend on are
completely
Post by Nir Lisker
Post by Sam Carlberg
empty.
You need to depend on "org.openjfx:javafx-base:11:$platform", where the
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The
website
Post by Sam Carlberg
Post by Nir Lisker
mentioned in 2 places that there are maven artifacts, but does not
mention
Post by Sam Carlberg
Post by Nir Lisker
their ID's, group etc. These are the downloads page [1] and the
getting
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
started page [2] (later you can see an example pom, but that doesn't count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it
finds
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the artifacts. It should be written in the above pages if this is
correct.
Post by Sam Carlberg
Post by Nir Lisker
On the usability side it's worse. I'm using Eclipse and during
compilation
Post by Sam Carlberg
Post by Nir Lisker
I'm getting error messages that JavaFX classes like BooleanProperty
can't
Post by Sam Carlberg
Post by Nir Lisker
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it will
solve
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/
[2] https://openjfx.io/openjfx-docs/#introduction
--
Michael Ennen
Scott Palmer
2018-09-30 21:19:18 UTC
Permalink
I thought he was saying the exact opposite.
You must specify the platform by using some mechanism in Maven (profiles?) or Gradle.

That’s what worked for me anyway.

Scott
Post by Michael Ennen
And just to reiterate and confirm for anyone trying to get a handle on using
the Maven artifacts - it is *NOT* necessary to manually specify the platform
classifier when using maven or gradle (nor add the automatic tricks to your
own project) because the JavaFX artifacts will automatically detect the
platform you are building on and pull in the correct artifacts, right?
Thanks for your work in this area Johan.
Post by Johan Vos
The problem with that is that there is no cross-platform version of the
jars itself. The windows-jar for the graphics module contains different
Java classes than the linux jar, for example.
The top-level API's are the same of course, hence the logical Java module
is the same, but different physical jars are really needed.
I realise this may be strange at compile time, where you only care about
the top-level API's. Therefore, people added nice "tricks" to both a
pom.xml and build.gradle system to automatically detect the current (host)
operating system, and making sure the correct artifacts are then used.
What I really wanted to avoid is that developers had to manually add their
platform (e.g. "win") in the build files, as this would break
cross-platform development (imagine you're in a team with a win and a linux
user, and they constantly change the pom.xml or build.gradle file for
this...).
I think the current solution deals pretty well with the current situations,
where there are different concepts in gradle/maven/sonatype and in the Java
module system.
- Johan
Post by Nir Lisker
Thanks Sam, that solved it. For some reason I was thinking that if you
don't specify the platform it downloads a version with all native
dependencies for cross compilation.
Post by Sam Carlberg
The libraries are in artifacts with platform-specific classifiers. The
artifacts with no classifiers that you currently depend on are
completely
Post by Nir Lisker
Post by Sam Carlberg
empty.
You need to depend on "org.openjfx:javafx-base:11:$platform", where the
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The
website
Post by Sam Carlberg
Post by Nir Lisker
mentioned in 2 places that there are maven artifacts, but does not
mention
Post by Sam Carlberg
Post by Nir Lisker
their ID's, group etc. These are the downloads page [1] and the
getting
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
started page [2] (later you can see an example pom, but that doesn't count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it
finds
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the artifacts. It should be written in the above pages if this is
correct.
Post by Sam Carlberg
Post by Nir Lisker
On the usability side it's worse. I'm using Eclipse and during
compilation
Post by Sam Carlberg
Post by Nir Lisker
I'm getting error messages that JavaFX classes like BooleanProperty
can't
Post by Sam Carlberg
Post by Nir Lisker
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it will
solve
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/
[2] https://openjfx.io/openjfx-docs/#introduction
--
Michael Ennen
Michael Ennen
2018-09-30 23:01:01 UTC
Permalink
Scott,

It seems that, for me at least, specifying the platform manually is not
necessary on
Maven but is necessary on Gradle. Looking at the POMs themselves it seems
that
the javafx-graphics, javafx-controls, etc. modules declare a dependency on
the
platform specific artifacts:

<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-base</artifactId>
<version>11</version>
<classifier>${javafx.platform}</classifier>
</dependency>

and declare as their parent:

<parent>
<groupId>org.openjfx</groupId>
<artifactId>javafx</artifactId>
<version>11</version>
</parent>

and the POM for that parent has the platform-specific Maven profiles
built-in.

So in other words the logic is already built in to the Maven POM and
therefore
works out of the box with Maven but Gradle does not re-use the Maven profile
logic in the POM.

Regards,
Michael Ennen
Post by Scott Palmer
I thought he was saying the exact opposite.
You must specify the platform by using some mechanism in Maven (profiles?) or Gradle.
That’s what worked for me anyway.
Scott
Post by Michael Ennen
And just to reiterate and confirm for anyone trying to get a handle on
using
Post by Michael Ennen
the Maven artifacts - it is *NOT* necessary to manually specify the
platform
Post by Michael Ennen
classifier when using maven or gradle (nor add the automatic tricks to
your
Post by Michael Ennen
own project) because the JavaFX artifacts will automatically detect the
platform you are building on and pull in the correct artifacts, right?
Thanks for your work in this area Johan.
Post by Johan Vos
The problem with that is that there is no cross-platform version of the
jars itself. The windows-jar for the graphics module contains different
Java classes than the linux jar, for example.
The top-level API's are the same of course, hence the logical Java
module
Post by Michael Ennen
Post by Johan Vos
is the same, but different physical jars are really needed.
I realise this may be strange at compile time, where you only care about
the top-level API's. Therefore, people added nice "tricks" to both a
pom.xml and build.gradle system to automatically detect the current
(host)
Post by Michael Ennen
Post by Johan Vos
operating system, and making sure the correct artifacts are then used.
What I really wanted to avoid is that developers had to manually add
their
Post by Michael Ennen
Post by Johan Vos
platform (e.g. "win") in the build files, as this would break
cross-platform development (imagine you're in a team with a win and a
linux
Post by Michael Ennen
Post by Johan Vos
user, and they constantly change the pom.xml or build.gradle file for
this...).
I think the current solution deals pretty well with the current
situations,
Post by Michael Ennen
Post by Johan Vos
where there are different concepts in gradle/maven/sonatype and in the
Java
Post by Michael Ennen
Post by Johan Vos
module system.
- Johan
Post by Nir Lisker
Thanks Sam, that solved it. For some reason I was thinking that if you
don't specify the platform it downloads a version with all native
dependencies for cross compilation.
Post by Sam Carlberg
The libraries are in artifacts with platform-specific classifiers. The
artifacts with no classifiers that you currently depend on are
completely
Post by Nir Lisker
Post by Sam Carlberg
empty.
You need to depend on "org.openjfx:javafx-base:11:$platform", where
the
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The
website
Post by Sam Carlberg
Post by Nir Lisker
mentioned in 2 places that there are maven artifacts, but does not
mention
Post by Sam Carlberg
Post by Nir Lisker
their ID's, group etc. These are the downloads page [1] and the
getting
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
started page [2] (later you can see an example pom, but that doesn't count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it
finds
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the artifacts. It should be written in the above pages if this is
correct.
Post by Sam Carlberg
Post by Nir Lisker
On the usability side it's worse. I'm using Eclipse and during
compilation
Post by Sam Carlberg
Post by Nir Lisker
I'm getting error messages that JavaFX classes like BooleanProperty
can't
Post by Sam Carlberg
Post by Nir Lisker
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it will
solve
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/
[2] https://openjfx.io/openjfx-docs/#introduction
--
Michael Ennen
Scott Palmer
2018-10-01 01:41:38 UTC
Permalink
I stopped using Maven years ago after switching to Gradle. So that could be right. I think there was an issue with Gradle processing transitive dependencies with a classifier or something. Thankfully Gradle makes it easy to specify the right classifier.

Scott
Post by Michael Ennen
Scott,
It seems that, for me at least, specifying the platform manually is not necessary on
Maven but is necessary on Gradle. Looking at the POMs themselves it seems that
the javafx-graphics, javafx-controls, etc. modules declare a dependency on the
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-base</artifactId>
<version>11</version>
<classifier>${javafx.platform}</classifier>
</dependency>
<parent>
<groupId>org.openjfx</groupId>
<artifactId>javafx</artifactId>
<version>11</version>
</parent>
and the POM for that parent has the platform-specific Maven profiles built-in.
So in other words the logic is already built in to the Maven POM and therefore
works out of the box with Maven but Gradle does not re-use the Maven profile
logic in the POM.
Regards,
Michael Ennen
I thought he was saying the exact opposite.
You must specify the platform by using some mechanism in Maven (profiles?) or Gradle.
That’s what worked for me anyway.
Scott
Post by Michael Ennen
And just to reiterate and confirm for anyone trying to get a handle on using
the Maven artifacts - it is *NOT* necessary to manually specify the platform
classifier when using maven or gradle (nor add the automatic tricks to your
own project) because the JavaFX artifacts will automatically detect the
platform you are building on and pull in the correct artifacts, right?
Thanks for your work in this area Johan.
Post by Johan Vos
The problem with that is that there is no cross-platform version of the
jars itself. The windows-jar for the graphics module contains different
Java classes than the linux jar, for example.
The top-level API's are the same of course, hence the logical Java module
is the same, but different physical jars are really needed.
I realise this may be strange at compile time, where you only care about
the top-level API's. Therefore, people added nice "tricks" to both a
pom.xml and build.gradle system to automatically detect the current (host)
operating system, and making sure the correct artifacts are then used.
What I really wanted to avoid is that developers had to manually add their
platform (e.g. "win") in the build files, as this would break
cross-platform development (imagine you're in a team with a win and a linux
user, and they constantly change the pom.xml or build.gradle file for
this...).
I think the current solution deals pretty well with the current situations,
where there are different concepts in gradle/maven/sonatype and in the Java
module system.
- Johan
Post by Nir Lisker
Thanks Sam, that solved it. For some reason I was thinking that if you
don't specify the platform it downloads a version with all native
dependencies for cross compilation.
Post by Sam Carlberg
The libraries are in artifacts with platform-specific classifiers. The
artifacts with no classifiers that you currently depend on are
completely
Post by Nir Lisker
Post by Sam Carlberg
empty.
You need to depend on "org.openjfx:javafx-base:11:$platform", where the
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The
website
Post by Sam Carlberg
Post by Nir Lisker
mentioned in 2 places that there are maven artifacts, but does not
mention
Post by Sam Carlberg
Post by Nir Lisker
their ID's, group etc. These are the downloads page [1] and the
getting
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
started page [2] (later you can see an example pom, but that doesn't count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it
finds
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the artifacts. It should be written in the above pages if this is
correct.
Post by Sam Carlberg
Post by Nir Lisker
On the usability side it's worse. I'm using Eclipse and during
compilation
Post by Sam Carlberg
Post by Nir Lisker
I'm getting error messages that JavaFX classes like BooleanProperty
can't
Post by Sam Carlberg
Post by Nir Lisker
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it will
solve
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/ <https://gluonhq.com/products/javafx/>
[2] https://openjfx.io/openjfx-docs/#introduction <https://openjfx.io/openjfx-docs/#introduction>
--
Michael Ennen
Nir Lisker
2018-10-01 10:53:55 UTC
Permalink
Well, whatever the case is, it needs to be tested and documented. If we
don't have that, we can't expect developers to use the library.

I can run a series of tests with both Maven and Gradle (on Win10 with
Eclipse).

- Nir
Post by Scott Palmer
I stopped using Maven years ago after switching to Gradle. So that could
be right. I think there was an issue with Gradle processing transitive
dependencies with a classifier or something. Thankfully Gradle makes it
easy to specify the right classifier.
Scott
Post by Michael Ennen
Scott,
It seems that, for me at least, specifying the platform manually is not
necessary on
Post by Michael Ennen
Maven but is necessary on Gradle. Looking at the POMs themselves it
seems that
Post by Michael Ennen
the javafx-graphics, javafx-controls, etc. modules declare a dependency
on the
Post by Michael Ennen
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-base</artifactId>
<version>11</version>
<classifier>${javafx.platform}</classifier>
</dependency>
<parent>
<groupId>org.openjfx</groupId>
<artifactId>javafx</artifactId>
<version>11</version>
</parent>
and the POM for that parent has the platform-specific Maven profiles
built-in.
Post by Michael Ennen
So in other words the logic is already built in to the Maven POM and
therefore
Post by Michael Ennen
works out of the box with Maven but Gradle does not re-use the Maven
profile
Post by Michael Ennen
logic in the POM.
Regards,
Michael Ennen
I thought he was saying the exact opposite.
You must specify the platform by using some mechanism in Maven
(profiles?) or Gradle.
Post by Michael Ennen
That’s what worked for me anyway.
Scott
Post by Michael Ennen
And just to reiterate and confirm for anyone trying to get a handle on
using
Post by Michael Ennen
Post by Michael Ennen
the Maven artifacts - it is *NOT* necessary to manually specify the
platform
Post by Michael Ennen
Post by Michael Ennen
classifier when using maven or gradle (nor add the automatic tricks to
your
Post by Michael Ennen
Post by Michael Ennen
own project) because the JavaFX artifacts will automatically detect the
platform you are building on and pull in the correct artifacts, right?
Thanks for your work in this area Johan.
Post by Johan Vos
The problem with that is that there is no cross-platform version of
the
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
jars itself. The windows-jar for the graphics module contains
different
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Java classes than the linux jar, for example.
The top-level API's are the same of course, hence the logical Java
module
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
is the same, but different physical jars are really needed.
I realise this may be strange at compile time, where you only care
about
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
the top-level API's. Therefore, people added nice "tricks" to both a
pom.xml and build.gradle system to automatically detect the current
(host)
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
operating system, and making sure the correct artifacts are then used.
What I really wanted to avoid is that developers had to manually add
their
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
platform (e.g. "win") in the build files, as this would break
cross-platform development (imagine you're in a team with a win and a
linux
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
user, and they constantly change the pom.xml or build.gradle file for
this...).
I think the current solution deals pretty well with the current
situations,
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
where there are different concepts in gradle/maven/sonatype and in
the Java
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
module system.
- Johan
Post by Nir Lisker
Thanks Sam, that solved it. For some reason I was thinking that if
you
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
don't specify the platform it downloads a version with all native
dependencies for cross compilation.
Post by Sam Carlberg
The libraries are in artifacts with platform-specific classifiers.
The
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
artifacts with no classifiers that you currently depend on are
completely
Post by Nir Lisker
Post by Sam Carlberg
empty.
You need to depend on "org.openjfx:javafx-base:11:$platform", where
the
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The
website
Post by Sam Carlberg
Post by Nir Lisker
mentioned in 2 places that there are maven artifacts, but does not
mention
Post by Sam Carlberg
Post by Nir Lisker
their ID's, group etc. These are the downloads page [1] and the
getting
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
started page [2] (later you can see an example pom, but that
doesn't
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it
finds
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the artifacts. It should be written in the above pages if this is
correct.
Post by Sam Carlberg
Post by Nir Lisker
On the usability side it's worse. I'm using Eclipse and during
compilation
Post by Sam Carlberg
Post by Nir Lisker
I'm getting error messages that JavaFX classes like BooleanProperty
can't
Post by Sam Carlberg
Post by Nir Lisker
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it will
solve
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/ <
https://gluonhq.com/products/javafx/>
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
[2] https://openjfx.io/openjfx-docs/#introduction <
https://openjfx.io/openjfx-docs/#introduction>
Post by Michael Ennen
Post by Michael Ennen
--
Michael Ennen
Johan Vos
2018-10-01 11:23:56 UTC
Permalink
Hi,

Have a look at the sample (maven/gradle) in
https://openjfx.io/openjfx-docs/

For maven, a pom.xml without any classifier is needed. This is because the
javafx module pom files have a javafx.pom as a parent, that will test the
current OS, and then use that as a classifier to download the correct
versions of the artifacts.

For gradle, the classifier needs to be in the build.gradle (e.g. see
https://openjfx.io/openjfx-docs/build.gradle) The logic in the sample shows
that the classifier can be detected though in the build.gradle.

- Johan
Post by Nir Lisker
Well, whatever the case is, it needs to be tested and documented. If we
don't have that, we can't expect developers to use the library.
I can run a series of tests with both Maven and Gradle (on Win10 with
Eclipse).
- Nir
Post by Scott Palmer
I stopped using Maven years ago after switching to Gradle. So that could
be right. I think there was an issue with Gradle processing transitive
dependencies with a classifier or something. Thankfully Gradle makes it
easy to specify the right classifier.
Scott
Post by Michael Ennen
Scott,
It seems that, for me at least, specifying the platform manually is not
necessary on
Post by Michael Ennen
Maven but is necessary on Gradle. Looking at the POMs themselves it
seems that
Post by Michael Ennen
the javafx-graphics, javafx-controls, etc. modules declare a dependency
on the
Post by Michael Ennen
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-base</artifactId>
<version>11</version>
<classifier>${javafx.platform}</classifier>
</dependency>
<parent>
<groupId>org.openjfx</groupId>
<artifactId>javafx</artifactId>
<version>11</version>
</parent>
and the POM for that parent has the platform-specific Maven profiles
built-in.
Post by Michael Ennen
So in other words the logic is already built in to the Maven POM and
therefore
Post by Michael Ennen
works out of the box with Maven but Gradle does not re-use the Maven
profile
Post by Michael Ennen
logic in the POM.
Regards,
Michael Ennen
I thought he was saying the exact opposite.
You must specify the platform by using some mechanism in Maven
(profiles?) or Gradle.
Post by Michael Ennen
That’s what worked for me anyway.
Scott
Post by Michael Ennen
And just to reiterate and confirm for anyone trying to get a handle
on
Post by Scott Palmer
using
Post by Michael Ennen
Post by Michael Ennen
the Maven artifacts - it is *NOT* necessary to manually specify the
platform
Post by Michael Ennen
Post by Michael Ennen
classifier when using maven or gradle (nor add the automatic tricks
to
Post by Scott Palmer
your
Post by Michael Ennen
Post by Michael Ennen
own project) because the JavaFX artifacts will automatically detect
the
Post by Scott Palmer
Post by Michael Ennen
Post by Michael Ennen
platform you are building on and pull in the correct artifacts,
right?
Post by Scott Palmer
Post by Michael Ennen
Post by Michael Ennen
Thanks for your work in this area Johan.
Post by Johan Vos
The problem with that is that there is no cross-platform version of
the
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
jars itself. The windows-jar for the graphics module contains
different
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Java classes than the linux jar, for example.
The top-level API's are the same of course, hence the logical Java
module
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
is the same, but different physical jars are really needed.
I realise this may be strange at compile time, where you only care
about
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
the top-level API's. Therefore, people added nice "tricks" to both a
pom.xml and build.gradle system to automatically detect the current
(host)
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
operating system, and making sure the correct artifacts are then
used.
Post by Scott Palmer
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
What I really wanted to avoid is that developers had to manually add
their
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
platform (e.g. "win") in the build files, as this would break
cross-platform development (imagine you're in a team with a win and
a
Post by Scott Palmer
linux
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
user, and they constantly change the pom.xml or build.gradle file
for
Post by Scott Palmer
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
this...).
I think the current solution deals pretty well with the current
situations,
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
where there are different concepts in gradle/maven/sonatype and in
the Java
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
module system.
- Johan
Post by Nir Lisker
Thanks Sam, that solved it. For some reason I was thinking that if
you
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
don't specify the platform it downloads a version with all native
dependencies for cross compilation.
On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg <
Post by Sam Carlberg
The libraries are in artifacts with platform-specific classifiers.
The
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
artifacts with no classifiers that you currently depend on are
completely
Post by Nir Lisker
Post by Sam Carlberg
empty.
You need to depend on "org.openjfx:javafx-base:11:$platform",
where
Post by Scott Palmer
the
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
platform is one of "win", "mac", or "linux".
Post by Nir Lisker
Hi,
I haven't kept up with all of the Maven artifacts discussion. The
website
Post by Sam Carlberg
Post by Nir Lisker
mentioned in 2 places that there are maven artifacts, but does
not
Post by Scott Palmer
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
mention
Post by Sam Carlberg
Post by Nir Lisker
their ID's, group etc. These are the downloads page [1] and the
getting
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
started page [2] (later you can see an example pom, but that
doesn't
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
count).
I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and
it
Post by Scott Palmer
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
finds
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the artifacts. It should be written in the above pages if this is
correct.
Post by Sam Carlberg
Post by Nir Lisker
On the usability side it's worse. I'm using Eclipse and during
compilation
Post by Sam Carlberg
Post by Nir Lisker
I'm getting error messages that JavaFX classes like
BooleanProperty
Post by Scott Palmer
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
can't
Post by Sam Carlberg
Post by Nir Lisker
be found. Is it a JavaFX problem, Eclipse problem, or me problem?
If I use the SDKs, can I point Gradle and Maven to them if it
will
Post by Scott Palmer
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
solve
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
the problem?
- Nir
[1] https://gluonhq.com/products/javafx/ <
https://gluonhq.com/products/javafx/>
Post by Michael Ennen
Post by Michael Ennen
Post by Johan Vos
Post by Nir Lisker
Post by Sam Carlberg
Post by Nir Lisker
[2] https://openjfx.io/openjfx-docs/#introduction <
https://openjfx.io/openjfx-docs/#introduction>
Post by Michael Ennen
Post by Michael Ennen
--
Michael Ennen
Loading...