On Jun 6, 2013, at 12:52 AM, Danno Ferrin <danno.fer...@shemnon.com> wrote:
> > > On Wed, Jun 5, 2013 at 9:47 PM, Daniel Zwolenski <zon...@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
