javafxpackager and launcher wrappers now in OpenJFX 8
zonski at gmail.com
Sun Dec 23 15:34:28 PST 2012
Some responses in-line below.
On Mon, Dec 24, 2012 at 9:42 AM, John Smith <send2jsmith at gmail.com> wrote:
> Are you just registering the group id for now or are you also uploading
Just registering the group for now and will look at uploading artifacts in
Jan when the rest of the deployment guys are back on board. Looks like I
need VisualStudio professional (i.e. $800 outlay and 8gb download) to be
able to build the tools so it will take me a little while to get that setup
Once we get access to the Maven group we can upload whatever artifacts we
want and it will be up to us to decide and manage them (e.g. I have similar
access to the group com.zenjava and can upload any artifact I want in this
group without any further approval, etc).
> What are the artifacts that will be uploaded to the maven repository, do
> you have a reference to them somewhere?
I'm planning to work this out with the deployment team in Jan, but my guess
it will be something like:
And maybe a couple of others, etc ,like the Main JFX prelauncher class,
Basically any of the JARs or built 'artifacts' that make up the current
deployment lib. Developers can then choose to reference them directly in
their own plugins, etc. I'll be using them from the Maven plugin but I
would suspect Gradle and others will want them too. Additionally, Eclipse
and IntelliJ could also use them but given they hook pretty directly into
the installed JDK, they might just take it from there.
> Are there any other openjdk bits in the Sonatype repository, if so what
> are their group ids?
You can ignore the 'Sonatype' side of it (see my next comment below) - it's
all about what's in Maven Central.
There isn't anything concrete in there but there are a few hits:
Maven is generally focused on 3rd party jars - there's not traditionally a
need to have any JRE libraries in there as you don't normally include them
on your classpath manually, etc. So I think openjdk stuff is probably not
generally in there. JFX falls into this same category and we don't
want/need the actual JFX runtime JAR in there. The deployment/build tools
however are something else again - they are not part of the JRE as such but
just happen to get bundled in with the JDK. For any of us building
customised build tools (like Maven plugins, IDE's, etc) we do want to
include these as 3rd party jars within our projects.
Regarding groupIds, etc, though it looks like we are more or less going
into new ground and should come up with a strategy that works for us.
What is the relationship between the Sonatype repository and Maven Central?
Maven Central is what it's all about. Whenever you, as a developer, do a
Maven build it checks against central for any JARs your project needs
(defined in the pom.xml) and downloads from there (you can configure other
options, but this is the default and by far the most common way).
It's not actually possible to deploy directly into the Maven repo though
(too messy for them to maintain I think) so they sort of out-sourced this
side of it. For Open Source projects Sonatype manages another repository
and provides any one with a genuinely open source project means to deploy
to it. The Sonatype repository is then synchronized to the main repo on a
You can think of Sonatype as the 'staging' repository - we upload to this
first and then it gets automatically pushed to Maven Central.
See this for some more info:
The actual process is not too hard but a bit involved - I've worked out
most of the tricks through deploying ZenJava stuff so I'm pretty
comfortable doing this side of it now.
That group id does seem a little bit long, but it probably doesn't matter
> that much.
Yea, just makes it easier for people to find.
I think it should be one of:
I quite like the first, but I think the second is more 'correct'. It's
really our choice though so if anyone has a preference, let me know. I
could for example deploy it under com.zenjava and no one would stop me.
I think there was also discussion about placing Wix in a repository? If so,
> where will that end up?
Yes, I have been working on this, and I just now pushed it into Sonatype.
It should get synced into Central sometime in the next 24 hours.
It will be available using:
You can search maven central for org.wixtoolset. When it shows up there it
is available. http://search.maven.org/#search%7Cga%7C1%7Corg.wixtoolset
I intend to make the JFX Maven Plugin automatically download this from
Central and then force the JFX deploy packaging tools (which I wrap in
Maven) to use this downloaded version. Much less hassle for developers, no
need to install anything, just run mvn jfx:build-native-win and magically
you get an MSI.
There's no reason why an ANT task, a Gradle plugin, and/or an SBT thing,
couldn't also download and do the same. I don't intend to do any of that
sort of coding, but if the people working on those need help, I'm happy to
> On Sat, Dec 22, 2012 at 12:04 PM, Daniel Zwolenski <zonski at gmail.com>wrote:
>> I lodged a request for this yesterday:
>> I went with the GroupId of net.java.openjdk.openjfx
>> Which seems to be the closest to the official domain for the project. I
>> thought net.java.openjfx would have been nicer, but it doesn't appear to be
>> If anyone has objections to this shout out quickly as I should be able to
>> change it before first deploy. Once something is in the central repo though
>> it's there for infinity and beyond - future versions can change/move but
>> that old version will always be there confusing things. Best if it's right
>> from the get-go.
>> On 23/12/2012, at 4:19 AM, Richard Bair <richard.bair at oracle.com> wrote:
>> >> The Sonatype guys (who we upload via) won't care if it is you or me
>> >> your licence gives me the right) but it will be deployed under the
>> >> (or "javafx.deploy") groupId.
>> > I would suggest that you should use "openjfx.deploy" and not use
>> "javafx.deploy". We should follow the pattern here of OpenJDK and Java.
>> OpenJDK is the open source project, with its own distinct set of binaries
>> from the commercial Java binaries. Likewise, JavaFX is the product that
>> Oracle produces based on the OpenJFX bits. Even if/when we get to the point
>> where the binaries are exactly the same, I'm sure the distinction will be
>> something Oracle will want to preserve.
>> > But there's no problem producing OpenJFX builds and such.
>> > Thanks!
>> > Richard
More information about the openjfx-dev