JavaFX Maven Plugin

[Daniel Zwolenski]

Ignore that bit about needing it open sourced to get the launch exe out - I
was being stupid, I should be able to extract it from the JDK directly,
dodging the legal issues. I will need the launcher code for AU though
eventually and it would be nice to be able to read through the code without
using a decompiler.

I think I can do nearly everything I need to by myself (just going to take
a heap of work) except for one thing that would open up a lot more options:

If the JRE for each platform was available as a zip for download from
somewhere public (i.e. that an automated program could download - none of
that annoying "accept the licence" thing) then this opens the road to
cross-platform native distros and simpler builds. It doesn't have to be in
a Maven repo, it can still have the same licencing restrictions, it just
needs to be publicly available without stop-gates in the way (e.g. a simple
download from java.com).

Technically this should be ridiculously easy and I think it would benefit
the regular JFX deployment tools a lot too. I could actually create the
zips but I'm not allowed to "distribute" the JRE, I can only "include" it
in my app.

The easiest way around this is for Oracle to be the distributor (as it is
now) but just provide (a) the download as a zip file for each platform and
(b) a way to download these zips without having to tick the "I accept the
licence" thing on the web page.

I know the second part will be the tricky one (kill all the lawyers) but if
someone from Oracle (e.g. the JavaFX packaging team) could do some pushing,
maybe it could happen sometime in the next year or two?






On Mon, Nov 26, 2012 at 8:13 AM, Jim Weaver <james.weaver at oracle.com> wrote:

> Daniel,
>
> +1 to Scott's sentiments about being glad that you're contributing to the
> vitally important JavaFX deployment effort!
>
> Thanks,
> Jim Weaver
>
> On Nov 25, 2012, at 2:25 PM, Scott Kovatch <scott.kovatch at oracle.com>
> wrote:
>
> > On Nov 25, 2012, at 3:29 AM, Daniel Zwolenski <zonski at gmail.com> wrote:
> >
> >> Hey guys,
> >>
> >> Is there any more news on the open sourcing of the packaging tools? It's
> >> been a "few days away" since October 27.
> >>
> >> What I'd really like to not have to rewrite are the native launcher
> >> executables that get bundled into the installers (i.e. the "exe" on
> >> windows). I can rip these out of the Java bundle for now to do my
> >> development but I won't be able to release my improved bundler until
> these
> >> bits are open sourced, giving me the legal all clear to include them in
> my
> >> plugin.
> >>
> >> Any chance I could get an actual timeframe on when the packaging tools
> are
> >> to be open sourced?
> >
> > I'm chugging along with this, but I was off last week due to the US
> Thanksgiving holiday.
> >
> > The code has been cleaned up (read: commented, TODO's removed/bugs
> created) and ready for review. There is some code we want to retire as part
> of this process, and that means modifying some makefiles and ensuring
> everything builds correctly in the closed repository, and then we can move
> it to the open  rt project in OpenJFX and make sure it builds there.
> >
> > So, it's happening, but there were some changes in assumptions I have to
> work around. Releasing something that won't build isn't helpful. I'll have
> a better timeframe early this week.
> >
> >> I'm doing my best to contribute what I personally think is vitally
> >> important for JavaFX. In general I'm accepting of the fact that what I'm
> >> doing is not something Oracle sees as overly important and I'm on my own
> >> (it's been quite a liberating attitude to take to be honest). Open
> Sourcing
> >> the packaging tools however, was something you said you were going to do
> >> anyway and it would save me having to write a whole new native launcher
> for
> >> each platform.
> >
> > I think it's great that you're interested in working on this. Deployment
> is not a glamorous job but it needs to be done. Without it, the rest of
> JavaFX isn't as useful, IMO.
> >
> > What we want to do is have a core API that's as tool-ignorant as
> possible, and then let developers like you put the tool frameworks around
> it. Right now we're closely tied to ant, and I'd like to get away from that.
> >
> > -- Scott K.
> >
> > ------------------------
> > Scott Kovatch
> > Oracle
> > Pleasanton, CA
> >
>