Reliable deployment idea: JNLP Launcher exe/dmg

[Daniel Zwolenski]

Hey Jeff,

I don't fully follow your suggestion (i.e. which bits are native, which
bits are Java and which bits are downloaded when) but I don't think it will
be quite as simple as this unfortunately (I've spent many a night laying
awake, staring at the ceiling trying to work out a clean way to do
deployment).

Maybe you could clarify some aspects of your suggestion though:



> What if we build a Netbeans JNLP launcher project


Do you mean a new open source Java project here that provides extra
deployment functionality that others can leverage? Or are you giving an
example of a user creating a new "GreatApp" project that they want to
launch?

Is your launcher project native code or Java code and what role does
Netbeans have in this (I wouldn't do anything IDE specific and passionately
disagree with the Netbeans bias of JFX - everything should be IDE
agnostic). How does the Launcher work and what does it do?


that you customize with just a link to a JNLP and a splash image,


Where does the JNLP come from, what is building it - are we just building a
normal JFX webstart bundle here or is this a special JNLP file?


and it builds your GreatApp.exe and GreatApp.dmg.


What builds this? To create an 'exe' you have to build on Windows (plus 32
bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you currently
have to be on Mac. There's no nice utility where you just go
build-me-all-my-installers-for-all-platforms. Partly this is due to
technology issues with each OS (e.g. MSI's can only be built on Windows)
and partly it is due to the JRE not being available for co-bundling
anywhere (the only one you have is the one installed on your machine), see
http://javafx-jira.kenai.com/browse/RT-22964

If this step was small and simple, the rest of it would be easy and we
wouldn't really need JNLP, webstart, etc.


The launcher app would simply fetch the JNLP, download the jars (if newer
> than cache), load them, and invoke MainClass.main().
>

This is what JNLP does at the moment. I assume you mean it add some value
somewhere but I'm missing what exactly that is? Note there is even a
pre-launcher MainClass in the JFX packaging tools that does some JFX checks
and updating stuff (it's weird and messy).


Then on your website you can say,
>
>         If you have Java, try the Web Start link [ here ] or
>         Download [ GreatApp.exe ] or [ GreatApp.dmg ]
>

In this case the JNLP file is a traditional one or something new and
special? If it is a traditional one then you cannot pin it to a JRE and
have all the problems we know about. If it is something special, I'm not
sure what that special is or how the specialness gets hooked into the
start-up process (since if you install Java the JNLP will be opened with
Java).

In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled into
them - i.e. they are just like the installers we can build now?

If the JNLP is not special and the native installers are the same as now
then I'm missing what you're adding to what we have now (i.e. you can
produce the above website right now)?

The only thing I think you might be suggesting is auto-updating of the
exe/dmg based apps, which is not currently supported but planned by Oracle
(unknown timeframe). Additionally there were a lot of discussions around
adding AU and I have put up prototype code for this that can be used to do
this (but it is raw and cludgy).

See this discussion:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html



>
> So the benefit over plain web start is that your GreatApp would have a
> consistent, self-contained execution environment, in the event that the
> target system doesn't have an installed JRE that is the right version or
> uncorrupted.


I'm missing how this happens? Can you clarify.


> You also don't get scary warning panels or signing issues.


Currently you don't have any of this with the native installers. The JRE is
co-bundled and never installed so you side-step the JRE installation
horrors.

The problems with native installers that need to be addressed are:
- Auto updating
- Reduce the JRE size to make smaller downloads
- Being able to build native releases on multiple platforms



>
> But you would still get the benefit of simple upgrades that WebStart gives
> you. And you wouldn't have to constantly generate a new .exe/.dmg (maybe
> once or twice a year if you decide a new JRE update would benefit your app).
>

This is basically just adding Auto Updating (AU) support to native
installers.

If your open source project is to add this then I'm in for that. I've
already done a POC: http://code.google.com/p/zen-update/source/browse/trunk/

I ported JFX Ensemble to include auto updating support:
http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe

Work on this stalled because the JFX deployment team were
unable/uninterested in implementing the changes needed to support this
work.

Once the packaging tools get open sourced (which is overdue) then the
community can take over this work (and it is on my todo list). So long as
the code remains behind the Oracle iron curtain however, we are hamstrung
unless we want to re-implement most of what they have done from the ground
up. This is an option but seems wasteful when the OS of the packaging code
is suppose to be soon (but "soon" seems to be a very loose term).


>
> Such a Netbeans project would probably only be a dozen pages of code.


Sounds ambitious :)


> Here's an even better idea - Oracle sets up a server that will take any
> JNLP link and dynamically generates a .exe/.dmg for us. :-)
>
>
You may be interested in this JIRA for this:
  http://javafx-jira.kenai.com/browse/RT-22994
  http://javafx-jira.kenai.com/browse/RT-22995

I'm keen to explore this topic with anyone and everyone wanting to do so. I
like that you are looking at it but I'm either missing something about your
suggestion or it's a bit too simple in it's approach to provide a solution.
If I'm missing something then I really want to know what! If I'm not then
I'm happy to help expose all the nasty complexities around this area if you
want.

Cheers,
Dan