JavaFX Maven Plugin

[Daniel Zwolenski]

Similar issues (give or take) for Maven as Danno has outlined.

More specifically, I use the classes in:

com.sun.javafx.tools.packager.*
com.sun.javafx.tools.packager.bundlers.*


Mostly this code just needs minor tweaks. As Danno said, things like it's
not possible to turn off JNLP, and there are some assumptions about
directories and the like that would ideally be configurable.

The (native) Bundler stuff is pretty hard to work with. It's suffering a
little from being an after thought I think, so not quite as clean as the
rest. It may just be that I'm missing something (working it out through a
decompiler is not the best way to understand someone else's code) but I
struggled to customise much of the native installer steps. As well as
needing changes, ideally someone writing this plugin would have docco on
this, and/or be able to shoot Igor questions like "How do I set the vendor
for a native installer?" and "How come when I override the app-name it
throws this error?", etc.

The other side of it is that I can't distribute this JAR (i.e. put it in a
Maven repo). The old legal problem. As such, I have to use reflection for
everything, which is a slow and painful way to code it.

e.g.

        Object deployParams = newInstance(deployParamsClass);
        invoke(deployParams, "setOutdir", outputDir);
        invoke(deployParams, "setOutfile", appDistributionName);
        invoke(deployParams, "setApplicationClass", mainClass);

Instead of

        DeployParams params = new DeployParams();
        params.setOutdir(outDir);
        params.setOutfile(appDistributionName);
        params.setApplicationClass(mainClass);

See this:
https://github.com/zonski/javafx-maven-plugin/blob/master/src/main/java/com/zenjava/javafx/maven/plugin/JfxToolsWrapper.java

Obviously makes it slower to write and harder and a disincentive to anyone
wanting to develop it further.

Simple solution, you guys put the 'tools' JAR up on a Maven repo (a "Maven
Repo" is any public webserver - you do NOT need to install anything or run
any processes other than an Apace, just follow a simple directory
structure, ridiculously easy, done in 10 minutes).

Alternatively, you relax the licence on this JAR and say it's ok for us
plebs to put it in a Maven repo.

The reflection works though.






On Tue, Oct 23, 2012 at 5:44 AM, Danno Ferrin <danno.ferrin at shemnon.com>wrote:

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