[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    JavaFX Maven Plugin
From:       richard.bair () oracle ! com (Richard Bair)
Date:       2012-10-26 15:26:08
Message-ID: A6CE83F2-FABC-4ADB-A4ED-633C1F093064 () oracle ! com
[Download RAW message or body]

We're going to open source dtjava.js and the packager in a couple days here I hope, \
but soon I any case.

Richard

On Oct 22, 2012, at 10:44 PM, Daniel Zwolenski <zonski at gmail.com> wrote:

> Similar issues (give or take) for Maven as Danno has outlined. 
> 
> More specifically, I use the classes in:
> 
> com.sun.javafx.tools.packager.*  
> com.sun.javafx.tools.packager.bundlers.*
> 
> Mostly this code just needs minor tweaks. As Danno said, things like it's not \
> possible to turn off JNLP, and there are some assumptions about directories and the \
> like that would ideally be configurable.  
> The (native) Bundler stuff is pretty hard to work with. It's suffering a little \
> from being an after thought I think, so not quite as clean as the rest. It may just \
> be that I'm missing something (working it out through a decompiler is not the best \
> way to understand someone else's code) but I struggled to customise much of the \
> native installer steps. As well as needing changes, ideally someone writing this \
> plugin would have docco on this, and/or be able to shoot Igor questions like "How \
> do I set the vendor for a native installer?" and "How come when I override the \
> app-name it throws this error?", etc.  
> The other side of it is that I can't distribute this JAR (i.e. put it in a Maven \
> repo). The old legal problem. As such, I have to use reflection for everything, \
> which is a slow and painful way to code it.   
> e.g. 
> 
> Object deployParams = newInstance(deployParamsClass);
> invoke(deployParams, "setOutdir", outputDir);
> invoke(deployParams, "setOutfile", appDistributionName);
> invoke(deployParams, "setApplicationClass", mainClass);
> 
> Instead of
> 
> DeployParams params = new DeployParams();
> params.setOutdir(outDir);
> params.setOutfile(appDistributionName);
> params.setApplicationClass(mainClass);
> 
> See this: https://github.com/zonski/javafx-maven-plugin/blob/master/src/main/java/com/zenjava/javafx/maven/plugin/JfxToolsWrapper.java
>  
> Obviously makes it slower to write and harder and a disincentive to anyone wanting \
> to develop it further.  
> Simple solution, you guys put the 'tools' JAR up on a Maven repo (a "Maven Repo" is \
> any public webserver - you do NOT need to install anything or run any processes \
> other than an Apace, just follow a simple directory structure, ridiculously easy, \
> done in 10 minutes).    
> Alternatively, you relax the licence on this JAR and say it's ok for us plebs to \
> put it in a Maven repo.  
> The reflection works though. 
> 
> 
> 
> 
> 
> 
> On Tue, Oct 23, 2012 at 5:44 AM, Danno Ferrin <danno.ferrin at shemnon.com> wrote:
> > Don't mean to threadjack, as I am not sure what Daniel Zwolenski may want,
> > but for my Gradle plugin there are some hard coded values that get in the
> > way:
> > 
> > * The parts that decide that "package/<platform>" is the magic directory to
> > look for native support files, so I can just point it at a different
> > directory for package
> > * The parts that decide which pieces to assemble, so I can turn off JNLP
> > generation and just generate .app or .exe
> > * The parts that decide the native packages should go into the 'bundles'
> > directory, so I can point it somewhere else.
> > * The parts that tie the need icon names in the native bundles to the app
> > name, so I can always name the files"applicationIcon," "installerIcon", or
> > whatever the build configures them to.
> > 
> > I wouldn't be surprised if these were deep in the code subject to audit.
> > 
> > On Mon, Oct 22, 2012 at 9:07 AM, Richard Bair <richard.bair at oracle.com>wrote:
> > 
> > > +1
> > > 
> > > Here's the basic problem I have. The deployment team is neck deep in
> > > security audits & security fixes. What parts of the deployment code need to
> > > be open sourced in order to make forward progress on this without waiting
> > > on the deployment team? Is that a possibility, or are the changes deep in
> > > deployment code?
> > > 
> > > Thanks
> > > Richard
> > > 
> > > On Oct 20, 2012, at 11:49 PM, Tom Eugelink wrote:
> > > 
> > > > Thanks for sharing Daniel!
> > > > 
> > > > 
> > > > On 2012-10-21 06:30, Daniel Zwolenski wrote:
> > > > > I have tidied up, and open sourced my JavaFX Maven plugin enough that it
> > > > > builds executable JARs (equivalent to the fx:jar ant task) and native
> > > > > bundles (equivalent to a subset of fx:deploy ant task):
> > > > > 
> > > > > https://github.com/zonski/javafx-maven-plugin
> > > > > 
> > > > > 
> > > > > I was waiting for the bootclasspath issue to get resolved to fix this up
> > > > > properly, but since I'm getting further and further away from JFX I
> > > figured
> > > > > better to tidy it up and hand it over to the community.
> > > > > 
> > > > > It does work perfectly well enough that you can use it to build real
> > > > > distributables of your app via Maven.
> > > > > 
> > > > > However it wraps only the basic JavaFX plugin features (i.e. you can't
> > > > > customise many of the settings), does not support Applets (dead anyway)
> > > or
> > > > > JNLP (I've never had success getting JNLP to actually work with JFX). It
> > > > > likely also has some platform specific bugs and problems, since I have
> > > > > tested only on Windows and building MSI's.
> > > > > 
> > > > > It would be relatively trivial (but time consuming) to extend it
> > > further.
> > > > > The code is simple but inelegant. Great improvements could be made if
> > > the
> > > > > JFX deployment team were to make some minor changes to their packaging
> > > API
> > > > > to make it easier to integrate with. And massive clean-ups could be
> > > made if
> > > > > they put their tools JAR in a Maven repo that they maintained.
> > > > > 
> > > > > I don't have any intention to develop this further or maintain it. It
> > > is a
> > > > > good base but it would be up to someone from the community to do this if
> > > > > they want it to do anything more than it does.
> > > > > 
> > > > > Note this plugin is to address the packaging/assembly issue. It does NOT
> > > > > solve the getting-jfx-on-the-classpath-issue. You still need to do
> > > whatever
> > > > > workaround you're doing now on that front.
> > > > 
> > > 
> > > 
> > 
> > 
> > --
> > 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
> 


[prev in list] [next in list] [prev in thread] [next in thread]