JavaFX plugin for SBT (original) (raw)

Danno Ferrin danno.ferrin at shemnon.com
Mon Nov 12 14:16:35 PST 2012

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/, mostly so I can point the jfx deployer at src/main. The ant task sniffs for package/ 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/. 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/ 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

More information about the openjfx-dev mailing list