JavaFX Maven Plugin (original) (raw)

Danno Ferrin danno.ferrin at shemnon.com
Mon Oct 22 11:44:25 PDT 2012


Don't mean to threadjack, as I am not sure what Daniel Zwolenski may want, but for my Gradle plugin there are some hard coded values that get in the way:

I wouldn't be surprised if these were deep in the code subject to audit.

On Mon, Oct 22, 2012 at 9:07 AM, Richard Bair <richard.bair at oracle.com>wrote:

+1

Here's the basic problem I have. The deployment team is neck deep in security audits & security fixes. What parts of the deployment code need to be open sourced in order to make forward progress on this without waiting on the deployment team? Is that a possibility, or are the changes deep in deployment code? Thanks Richard On Oct 20, 2012, at 11:49 PM, Tom Eugelink wrote: > Thanks for sharing Daniel! > > > On 2012-10-21 06:30, Daniel Zwolenski wrote: >> I have tidied up, and open sourced my JavaFX Maven plugin enough that it >> builds executable JARs (equivalent to the fx:jar ant task) and native >> bundles (equivalent to a subset of fx:deploy ant task): >> >> https://github.com/zonski/javafx-maven-plugin >> >> >> I was waiting for the bootclasspath issue to get resolved to fix this up >> properly, but since I'm getting further and further away from JFX I figured >> better to tidy it up and hand it over to the community. >> >> It does work perfectly well enough that you can use it to build real >> distributables of your app via Maven. >> >> However it wraps only the basic JavaFX plugin features (i.e. you can't >> customise many of the settings), does not support Applets (dead anyway) or >> JNLP (I've never had success getting JNLP to actually work with JFX). It >> likely also has some platform specific bugs and problems, since I have >> tested only on Windows and building MSI's. >> >> It would be relatively trivial (but time consuming) to extend it further. >> The code is simple but inelegant. Great improvements could be made if the >> JFX deployment team were to make some minor changes to their packaging API >> to make it easier to integrate with. And massive clean-ups could be made if >> they put their tools JAR in a Maven repo that they maintained. >> >> I don't have any intention to develop this further or maintain it. It is a >> good base but it would be up to someone from the community to do this if >> they want it to do anything more than it does. >> >> Note this plugin is to address the packaging/assembly issue. It does NOT >> solve the getting-jfx-on-the-classpath-issue. You still need to do whatever >> workaround you're doing now on that front. >

-- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07



More information about the openjfx-dev mailing list