Maven support

[Will Hoover]

If your JSON service has a backing POJO model you can use something like
this: http://wp.me/p2rLDc-1c

-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net
[mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Mark Fortner
Sent: Monday, October 15, 2012 6:40 PM
To: openjfx-dev at openjdk.java.net
Subject: Re: Maven support

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