JFX Packager (was Re: Preloaders)

[Daniel Zwolenski]

On Thu, Jun 6, 2013 at 5:52 PM, Danno Ferrin <danno.ferrin at shemnon.com>wrote:

>
>
> On Wed, Jun 5, 2013 at 9:47 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
>
>> To sum up my previous major suggestions for a better world:
>>
>> - web deploy code should be separate module from native, and jar separate
>> again. Each native module (win, Linux, Mac) should be separate and I should
>> be able to invoke any and all of them how and when I want, not just one
>> generateDeployment method as the only entry point.
>>
>>
> I think JNLP and web generation should be a bundler on the same level as
> win/mac/lin.  No special treatment, it is just hte same as the rest
>

Agreed, they are all the same level, but modularised at a code level so we
can call generateJnlpBundle or generateWinExeBundle, generateWinMsiBundle.
Currently there's this uber bundle going on that you can
sort-of-if-you're-lucky turn some bits off. It's this uber bundling I'd
like to see change in the future. Give me finer hook in points for the
Maven plugin anyway.


> - java code of packager should be one library for all platforms so we have
>> one jar for all, not a separate one for each OS. Native bits are referenced
>> from this one jar as needed.
>>
>
> I actually disagree with this.   Perhaps the default bundlers come in one
> jar for hte JDK, but I would like the ability to add bundlers external to
> the tool that evolve at different speeds than the core JDK.  Tha was the
> point of my service loader patch.  Making the bundlers separate for the JDK
> is a good exercise in proving severability.
>

Agree to being to add your own customisations by the core tools having
plugin points. Also would love to see the packager tools not tied into the
JDK and be on their own release cycle - this would be a massive win (wasn't
a popular suggestion when I made it a while back).

My point about "one jar" was more to do with the fact that currently the
"ant-javafx.jar" at the moment is different in the Mac distro of the JDK to
the Window version of the JDK, which is different again to a 32bit version
of the "ant-javafx.jar" on a 32 bit windows JDK.

95% of the code is the same in all of these however there are slight
differences to the Java code (or so I was told - by Ivan I think) and the
native bits (winlauncher.exe for example) are included in the JAR (from
memory). So effectively the "ant-javafx.jar" is platform specific.

Messy to get all those platform specific JARs and put them in Maven (or
whatever). You need to reference the right JAR for the platform you are on,
even for doing, say a web build, which doesn't actually care.

Also the native inter-twining makes it hard to build for testing and
contributing, since I need to do the native builds, whereas if these were
separate assets I could just mess with the Java code and use the native
bits out of the repo.

So when I say "one jar" maybe translate that to "not platform specific JARs
of stuff that doesn't need to be".



> - native should not have dumb stuff from web as a requirement if not used.
>> Signing, special jfx meta-inf in jars, checking registry for jdk, etc, etc.
>> Native is actually very simple and really should be able to work with a
>> stock standard jar and not need a special jfx built one. Web should be
>> quarrantined so that native isn't sullied by it.
>>
>
> Sullied is a bit of a harsh word.
>

I'm afraid I've come to hate the web deployment stuff (partly
disappointment because it held so much potential). The code in the packager
is really messy and makes me angry when I try and work with it. Most of it
is over engineering as far as I can tell. It also doesn't work reliably.
And web deploy is the reason security problems are possible. And... I'll
stop there.

Unfortunately, native bundles were an after thought and just tacked on. The
Native bundler code in the packager is tightly intertwined with this web
code currently. I'd like to see that change.  e.g. Why do we need version
checks on JRE's etc, when we have a co-bundled JRE in our native app?


> Deployment modes are different   For example, a Mac App, iOS app, and
> Android APK all still need to be signed, their deployment models for
> signing are different.
>

Yep, agreed.

My preference is that each one should be a separate module in the packager,
so they can each do whatever is special for them. APK should not have
complexities resulting from native, and native not from web, and web not
from APK, etc. Each module should deal with the job of building a distro
for that platform in the simplest and cleanest way.

There would definitely be some re-used code (like signing) that is in a
common spot but at the moment the native launcher depends on a JFX built
JAR which includes stuff only needed for web, etc.

And I agree, I should be able to build my own custom bundle builder that
just slots into the framework alongside the others. I should be able to
leverage the common code (like signing) from my custom module.


>
>
>> - no magic config in the core libraries (higher wrappers can try and add
>> it on top). Eg It shouldn't look for wix and use it just because it's
>> installed. I should be able to specify I want wix or inno and tools should
>> fail if they are not there.
>>
>
> I still think there is a role for the "all" packaging type that would do
> all the ones it has access to and work.  However I wouldn't want to see it
> fail unless specifically called out.  i.e. the WIX bundler would fail if
> 'wix' was in the packaging types, but not if 'all' was the packaging type
> that called it. This is really a per-bundler decision.
>

I feel like this is a higher level thing. So the ANT tasks (and the Maven
and Gradle plugins could add this), but the core library offers us small
lego building blocks to use as we see fit. The core library could even have
this higher level option, so long as it gives me the lower level hook ins.

So mvn jfx:all could do exactly what you said, but I'd like the tools to
give me the ability to do mvn jfx:webstart, mvn jfx:win-exe or mvn
Jfx:win-msi. Currently, the packager tools don't allow this sort of
granularity to be implemented easily.


That's just looking at improvements to what's already there. As far as my
>> picks for new features, these would be my top:
>>
>> - app store support (desktop at this stage)
>>
>> - auto updating support for native bundles
>>
>> - cross platform builds on the one machine (ie build for Mac from a
>> windows machine, etc). Also build a 32bit distro on a 64bit jdk, etc.
>>
>
> Or build RasPi debs on a linux vm.
>
>
>> - compact jre's for smaller distro sizes.
>>
>
> ^^^^ THIS ^^^^
>
> --Danno
>