Maven support

[Mark Fortner]

Hi Dan,
Along the lines of "things that I'd like to see, but not necessarily Maven
related", it would be really useful if data and service binding were
easier/possible.  I'd like to be able to click on a combobox and point to
the JSON service that supplies the data for the combobox. And then point
the onSelect event handler to the service responsible for persisting the
selection.  When Rave came out this was one of the features that really
caught developers eyes and made them reconsider JSF.  Admittedly people
have backtracked on that decision, but it's definitely something that would
speed up the development process.

Cheers,

Mark




On Mon, Oct 15, 2012 at 3:29 PM, Daniel Zwolenski <zonski at gmail.com> wrote:

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