JavaFX Maven Plugin

[Daniel Zwolenski]

Since I first posted this, I have:

   - pushed this Maven plugin into the central repository so you no longer
   need to reference my private repository for it.
   - added a "mvn jfx:fix-classpath" command which puts the jfxrt.jar on
   the bootclass path (by copying it into the ext directory as per the plan
   for Java 8)
   - added an example project that uses the plugin and that can be used as
   a template/kickstarter.

All the details are on the GitHub project:
https://github.com/zonski/javafx-maven-plugin

I am considering adding things to this project.

1. Richard is there any more word on when the JFX build tools may be open
sourced?

2. Danno are you still developing the Gradle plugin (what is it's website)?
If so I think it would be good if we standardised on directories for
certain things as there are concepts in this type of packaging that Maven
hasn't really covered before AFAIK. e.g. where best to put templates for
JNLP files and Applet HTML templates, etc. Also including native
dependencies can be tough in Maven and a best practice for this would be
good, etc.






On Sat, Oct 27, 2012 at 2:26 AM, Richard Bair <richard.bair at oracle.com>wrote:

> We're going to open source dtjava.js and the packager in a couple days
> here I hope, but soon I any case.
>
> Richard
>
>
> On Oct 22, 2012, at 10:44 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
>
> 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
>>
>
>