JavaFX plugin for SBT

[Danno Ferrin]

On Sun, Nov 11, 2012 at 9:32 PM, Daniel Zwolenski <zonski at gmail.com> wrote:

> Looks good. Standardisation would be great wherever appropriate.
>
> I'm considering adding JNLP and Applet support to the Maven plugin. For
> these I think I would like to support:
>
>    - Auto generation of a JNLP file based on the POM details (with optional
>    templating system to customise it)
>    - Auto generation of a HTML page based on the POM details which links to
>    the JNLP file (with optional templating)
>    - Auto generation of a HTML page based on the POM details for Applet
>    (with optional templating)
>

There also needs to be a "use this file" support.  Auto-generation is nice
but sometimes there are random things that have to be put in
for random reasons that the conventions don't support.


> (I need to look into the existing JFX Packager tooling to see how much of
> this it does and how much would be new code but regardless this would be
> the goals)
>

The JNLP is auto generated based on what you pass into the ant task.


>
> Assuming the Gradle and SBT tools are wanting to do something similar (?)
> then I guess we need some standard directories for the templates, maybe:
>
>     src/main/webstart <-- contains jnlp template and html template for
> launching the jnlp
>     src/main/applet <-- contains html template for launching the jnlp
>
> Thoughts?
>

Right now I have the gradle plugin set up for src/main/package/<platform>,
mostly so I can point the jfx deployer at src/main.  The ant task sniffs
for package/<platform> in the classpath, so that is why I did id that way.


>
>
> Do you guys use the 'target' directory as the output directory in Gradle or
> SBT? Do we need to standardise on output directories, or is this every man
> for himself?
>

Gradle defaults to 'build' and has a different sub-structure from Maven.
 SBT uses 'target'.


> Currently I'm using target/javafx as the base of the output - unless there
> are objections I will look at putting each "bundle" under there, along the
> lines of:
>
>   target/javafx/jar
>   target/javafx/webstart
>   target/javafx/applet
>   target/javafx/installer
>   target/javafx/installer/win/win-x86
>   target/javafx/installer/win/win-x64
>
> Not sure whether the JFX packaging tools will let me actually do this
> without customisations - will see.
>
> Waiting on that open sourcing to happen before doing too much of the above
> though...
>

The Gradle plugin uses build/distributions/bundles/<file>.  The bundles
part is from the jfx deploy tasks and the distributions part is a gradle
thing.

I don't like target/javafx.  My main reason is that the random user who
clones a github project and builds it locally shouldn't be reminded at
every turn of the particular choice of GUI toolkit.

I feel we should try to model off of what other plugins have done with
regard to native deployments.

For example, the Maven DMG plugin  (
http://mojo.codehaus.org/osxappbundle-maven-plugin)
uses src/main/app-resources for soruce data and drops the DMG directly into
target/

My first set of patches off the distribution code will likely be code to
allow us to change some of the hard coded input and output directories, so
we can do src/main/app-resources/<platform> and drop stuff info
target/installers directly.  And turn off JNLP unless asked for explicitly.


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