What you suggest would not be possible without considerable refactoring
of the modules with native code, since the Java module system does not
allow modules to be split across jars.
-- Kevin
On 8/27/2018 12:02 PM, Sam Carlberg wrote:
It would be moving the platform-independent classes (ie the public API)
into the empty jars, leaving the platform-specific classes and binaries
where they are in the platform JARs. The service loader mechanism seems
suitable for tying the APi and platform modules together at runtime.
I don't think module-info is suited for dependency management. It has no
way to specify versions or platforms (or classifiers in general). Maven and
Gradle will still need that information to be able to resolve artifacts.
On Sun, Aug 26, 2018 at 10:05 AM Johan Vos <johan....@gluonhq.com> wrote:
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
- Johan
On Fri, Aug 24, 2018 at 11:34 PM Sam Carlberg <sam.carlb...@gmail.com>
wrote:
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
