Why are there only platform-specific Maven artifacts?
johan.vos at gluonhq.com
Sun Aug 26 14:05:23 UTC 2018
The platform-specific code is a general Java issue that needs to be solved
one day. Your suggestion basically comes down to moving the classfiles from
the platform-specific jars into the empty jars, right?
A problem with this is that currently, the jars are platform-dependent as
well (e.g. no OpenGL on win).
Apart from that, your comments about libraries make sense: libraries don't
care about platforms. But I think this could be better fixed at the level
of the build tools (maven/gradle), combined with the module-info: if your
library depends on e.g. javafx.controls, it should be enough to have that
in your module-info.java.
The current situation is an artificial semi-parallel dependency system,
where dependencies are added with classifiers in e.g. build.gradle or
pom.xml and without classifiers in module-info.java
On Fri, Aug 24, 2018 at 11:34 PM Sam Carlberg <sam.carlberg at gmail.com>
> As I see it, providing only platform-specific artifacts makes it difficult
> or impossible for third-party JavaFX libraries or frameworks to depend on
> the JavaFX API and pass it along to consumers. Libraries don't care about
> the platform-specific code - that's up the final application to determine -
> but are forced to arbitrarily choose one of the Windows, Mac, or Linux JARs
> anyway. I suppose they could use a compileOnly configuration, but that
> forces all downstream consumers to re-declare the JavaFX dependencies (and
> keep track of the dependencies of the library, too!)
> IMO it makes more sense to publish the general API classes into a
> classifier-less JAR (which are now the "empty JARs") and place the
> platform-specific classes and binaries in platform-specific artifacts with
> a different name. For example, JavaFX could have a "javafx-graphics"
> artifact for the platform-agnostic classes, and a `java-graphics-platform"
> for platform-specific code, with classifiers to specify the platform. This
> does run into the "empty JAR" issue again, but it'd be limited in scope to
> only the final application.
> Sam Carlberg
More information about the openjfx-dev