Maven support

[Daniel Zwolenski]

Hi Mark,

You have summed up the Maven requirements perfectly. A few comments inline
below.

On Tue, Oct 16, 2012 at 7:55 AM, Mark Fortner <phidias51 at gmail.com> wrote:

> There have been several discussions in the past six months about Maven
> support in JavaFX and I wanted to re-open the topic and perhaps get a
> comprehensive and current must-have list before filing an issue on it.
>

Great to have this comprehensive list, however be aware that numerous
issues exist in JIRA already (search for Maven) and there have been several
energetic attempts to get some movement here. Several of the issues have
been closed previously by the JFX team with some key ones as "Won't fix".

In general the Oracle guys are officially "hands off" on Maven (and all
non-ANT build tools). On the flip side the community has been unable to
progress this because of some of the issues. You will likely find that the
Maven+JFX advocates have either given up or are waiting for true
co-bundling or total open sourcing before doing anything further.



>  Here's my list:
>
>    - Create a Maven archetype to generate a JavaFX project skeleton.  The
>    archetype would:
>       - Generate the appropriate folder structure including a folder for
>       distribution resources like the splashscreen.
>       - Generate a POM file with the appropriate dependencies.
>       - Generate Maven goals for creating:
>          - JNLP
>          - Double-clickable JAR
>          - Windows executable
>          - Linux RPM and Deb files
>          http://mojo.codehaus.org/rpm-maven-plugin/,
>          http://mojo.codehaus.org/deb-maven-plugin/
>          - Mac DMG file:
> http://mojo.codehaus.org/osxappbundle-maven-plugin/
>       - Handle signing of the JARs (including dependencies).
>

Yes to all.

For those not used to Maven, this is effectively the 'plugin' side of it
that I was talking about in my previous email. i.e. the bit that needs
doing *after* the bootclasspath issue is finally resolved.

   - Generate the source, and javadoc artifacts and install them in a
>    public repository.  Even though the JavaFX binaries are being
> distributed,
>    the source and the JavaDoc are not, which makes debugging a pain.
>

There may be some Issues with version management on this one (i.e. the
Maven plugin having a different version to the runtime).

Since JFX is "part of Java" (or trying to be), JFX should do whatever Java
does in this space in my opinion.


> The POM should have no native dependencies.  Development shops typically
> have a build machine (usually Linux) that runs automated builds, and the
> machine should be able to build any platform-specific executable.
>

This is definitely the ideal, and one of the major drawbacks/show-stoppers
to cross-platform JFX at the moment (i.e. the current native build process
is only slightly better than say a C++ native build).

This issue applies equally to the ANT tasks. I created this issue a while
ago: http://javafx-jira.kenai.com/browse/RT-22994

This is currently not possible for native installers. Some very major work
would need to be done on the way the native builds work and there's not
been any public discussions indicating this is something the JFX team is
looking into.



> The POM shouldn't rely on Ant calls.  The Maven plugin should be
> self-contained and easily configurable.
>

I started work on this plugin (maybe a year ago or so). The ANT tasks call
onto the 'packager' library and the Maven plugin could/should do the same.
The packager code is quite clean and abstracted away from ANT. There is
definitely no *technical* need for either the developer or the plugin to
call out to ANT as an intermediary.

The actual implementation of the plugin is actually quite straight forward
(though time consuming). I abandoned my plugin development due to two
hurdles:

1) Oracle legal restrictions against putting the JARs in a public repo and
2) The native DLL loading of JFX is not Maven friendly (so even if you put
the JARs in yourself it's still very messy)

There was no movement from Oracle in addressing either of the above.

The move to co-bundling (which will only be complete when the bootclasspath
issue is resolved) will render both of these issues irrelevant so Maven+JFX
users have been waiting (and waiting) for this before doing anything
further on it.



> Once the basics are sorted out, it would be good to re-examine how
> developing JavaFX apps could be made even easier with Maven.  For example,

it might be nice to autogenerate these "Observable" POJOs from POJOs that
> already exist and are being used on the server.  Imagine having the JavaFX
> version of Spring ROO or Grails where the forms and controllers you need
> are automatically generated.  This would make it easier the prospect of
> transitioning to a new toolkit less daunting, and make it possible to build
> on the infrastructure and services that you already have in place.


Some RAD tools would be awesome. I don't think this is Maven's space though
but definitely within the ROO and Grails space. SceneBuilder is the 'RAD'
tool of the JFX platform but it is basically an FXML WYSIWYG editor.

All of the above would aid adoption of JFX but all of the above has been
discussed at length before without much actual progress.