[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    maven artifacts
From:       Johan Vos <johan.vos () gluonhq ! com>
Date:       2018-06-24 18:41:37
Message-ID: CABxFH2Ho1V4MTJROho2RQ2QZOLhJD6FN1ryzTQxNXkuTz6O9HA () mail ! gmail ! com
[Download RAW message or body]

As discussed before, there will be at least 2 ways developers can work with
JavaFX 11 and beyond:
1. use the standalone SDK, with platform-specifc distributions
2. use artifacts on (remote) repositories

For the second option, we have to distinguish between build systems (e.g.
maven/gradle) and repositories (e.g. maven central).

When we put artifacts on remote repositories (e.g. maven central), the
build systems will download them, analyse the dependencies, and
transitively download other dependencies.
Build systems at the very least allow developers to compile Java code, so
they have the notion of classpath/modulepath.

With the work done in PR#83 (
https://github.com/javafxports/openjdk-jfx/pull/83) we are ready to upload
artifacts to remote repositories.

While it is working with both maven and gradle, I'm not 100% happy yet, but
I don't think there is a perfect solution.
Maven and gradle rely on the concept of a pom file to define dependencies,
while the Java Module System depends on a module-info file. While those 2
concepts target different aspects of the lifecycle, there is overlap.

If we offer 2 options (standalone SDK and remote artifacts), the most
important requirement is that developers can easily switch between these
options without changing a single line of code in a .java file. As a
consequence, the module-info.java need to work with standalone SDK's and
remote artifacts.
If an application declares a requirement on javafx.controls, that should be
in its module-info.java. Next, when the javafx controls module is
installed, its module-info.class should be independent on how it is
installed (either available in the SDK or via a remote repository)
As long as maven or gradle don't analyse module-info files inside jars, we
have to use the pom dependencies to make sure maven/gradle understand that
using javafx.controls implies using javafx.graphics.

So far no problems, this can be automated (see
https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1583)
in our build.gradle. The pom files will have a dependency for every project
dependency.

The difficulty is in handling platform-specific installations in a
standardized way, taking into account the existing reality.
Some JavaFX modules require platform-dependent native libraries, and/or
contain platform-specific class files (e.g. d3d files only make sense on
windows).
In the standalone SDK's, this is solved by having completely separate
downloads for each platform.
The way we did it in PR #83 is more or less similar: we have different
artifacts for the different platforms. where we use a classifier for
determining which platform is needed.
This ensures that if you depend on e.g. javafx.controls for linux, the
build system (maven/gradle) will also make sure to download javafx.graphics
for linux. This information is in the pom.xml, as the module-info.java is
platform-independent.

We have a parent file called javafx.pom (
https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-767d20a82f9dd4b7e319feefc33b89e6)
that sets the classifier to ${javafx.platform} which is initialized to ${
os.name}. That parameter is available on maven, so if you use maven and
don't do a cross-platform build, not specifying a platform will download
the artifacts for your specific platform.
If you're using gradle, or want to do a cross-platform build. you have to
specify the platform you want to use.

It seems to me this system is most close to what developers currently are
used to.

- Johan
[prev in list] [next in list] [prev in thread] [next in thread]