Putting the JavaFX 78 backport into Maven Central

Daniel Zwolenski zonski at gmail.com
Mon Jul 29 14:58:16 PDT 2013

As I mentioned, I'm in the process of deploying the iOS version of Danno's
78 backport (https://bitbucket.org/narya/jfx78) to Maven Central. This is a
summary of a couple of decisions I'm taking.

*78 Backport Coordinates *

I previously proposed deploying with these coordinates:

   - groupId=net.java.openjfx
   - artifactId=openjfx-78-backport
   - version=1.8.0-ea-b96.1
   - classifier=ios

The native files would use the same coordinates, except with an artifactId
of openjfx-78-backport-native.

Given the backport is quite different to the official stuff, in order to
keep things clean down the road, I'm now thinking of using a specific group
for the backport, so:

   - groupId=net.java.openjfx.backport
   - artifactId=openjfx-78-backport
   - version=1.8.0-ea-b96.1
   - classifier=ios

If there are any objections or better ideas, shout out as soon as possible.

*Classifiers for OS and default JARs*

I hit a problem in that in order to pass the rules for submitting, I need
to have an unclassified (default) JAR file. There is no such JAR in jfx
since all JARs are platform dependent. Sonatype have recommended I pick one
of the OS dependent JARs and use that as the default (yuck). In the case of
the backport I am only building the ios one, so this is going to be the
easiest default JAR for me to deploy. If anyone has any objections to that,
or better ideas - shout out as soon as possible.

If we ever get to the stage of deploying the official openjfx modules then
we will be faced with the decision of which one is the 'default'. I'll
leave that alone at the moment, but Richard, if you are looking at using
repos, this might be something to keep in mind (ideal would be to do the
split I mentioned in a previous email).

Compatibility classes*

JavaFX 8 is using classes in the JDK that are not available in Java7. For
the backport to work there were two choices, either edit the JFX code to
not use these classes, or make these classes available to the backport.
Danno and Niklas decided to go for the second option, and there is now
another mini-project containing these classes so they can run on Java7.

I am also going to push these into Maven (I need to do some work on the POM
in this first). The coordinates are a little tough for this, but I'm
thinking of using:

   - groupId=net.java.openjfx.backport
   - artifactId=openjfx-78-backport-compat
   - version=

The version is tricky. It's unlikely this compatibility stuff will change
much with each release of JFX, so I don't really want to tie it into the
version number of that (e.g. 1.8.0-ea-b96.1) and then have to redeploy an
identical JAR each time. At the same time, we will likely want to add
things over time that we missed, etc, so we do need a version number we can
increment. I'm using the .1 on the end for this.

This versioning is not overly intuitive, but it's the best I can come up
with. Objections, suggestions, shout out.

*POM file info*

To deploy to Sonatype and pass their checks, I have to fill in various
sections of the POM such as licencing information, URLs, list of
developers, etc.

I've attached the POMs which are fleshed out as best I can and should pass
the checks. If anyone wants anything different or sees any problems, shout.

The developer section I have stuck in Danno as Project Owner and myself as
Maven Deployer. The idea of this section is that it provides a reference
point to the people working on the project so someone could track them down
later. I don't really care who or what goes in here.

More information about the openjfx-dev mailing list