Preloaders

[Mark Howe]

On Jun 6, 2013, at 12:52 AM, 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
> 

What I don't like is bundling feels like a soup, where u throw a bunch of component in together. Some overlap and some don't and it's not clear what is being generate by each piece. Sometime it's affecting jnlp and native, sometimes not. This creates a very confusing API. I would much rather do my jnlp separate from native. Maybe there is some other way to share declarations,  like create a reusable declaration set.

In other words they should be separate bundlers, jnlp should be independent of native (they still leverage the same libraries. 

This should also allow bundlers to be registered for features we haven't thought of yet.


>  
> - 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.
> 

I don't think it matters too much, as long as bundlers can be separate and hopefully dynamically loaded.


>  
> - 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.  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.

They should be separated but should share API's to accomplish there own goals. "there too much confusion here, said the joker to the thief", the ant api/functionality is all mixed together.


>  
> - 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.


Explicit is good, Convention over configuration where it makes sense :)


>  
> 
> 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.

Separate installable bundlers 

>  
> - compact jre's for smaller distro sizes.
> 

All the above :)


> ^^^^ THIS ^^^^ 
> 
> --Danno