JavaFX Maven Plugin

[Danno Ferrin]

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:

* The parts that decide that "package/<platform>" is the magic directory to
look for native support files, so I can just point it at a different
directory for package
* The parts that decide which pieces to assemble, so I can turn off JNLP
generation and just generate .app or .exe
* The parts that decide the native packages should go into the 'bundles'
directory, so I can point it somewhere else.
* The parts that tie the need icon names in the native bundles to the app
name, so I can always name the files"applicationIcon," "installerIcon", or
whatever the build configures them to.

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