JavaFX Maven Plugin

[Richard Bair]

+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.
>