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 >> > -- Sam Carlberg
