Preloaders

[Daniel Zwolenski]

To sum up my previous major suggestions for a better world:

- everything should be easily configurable via runtime params passed to packager code: input paths, output paths, paths to native tools, resources, includes, file names, etc. Everything!

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

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

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

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

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. 

- compact jre's for smaller distro sizes. 

Just a little wish list :)

Cheers,
Dan



On 06/06/2013, at 1:15 PM, Danno Ferrin <danno.ferrin at shemnon.com> wrote:

> For me the biggest add would be for some form of runtime configuration of the packager, as well as the bundler params.  this would allow outside contributors to cerate an APK bundler or an iOS bundler of many forms without having to adjust the core code, and allowing them to be brought in at "runtime" (the runtime of the build).  This also extends to the bundle params having an open-ended property set of some sort, so things that matter to random packaging formats don't leak into other bundle params.  My dream would be to be able to create an APK or other such bundle just by flipping a param in the packager call form an otherwise desktop app.
> 
> On Wed, Jun 5, 2013 at 8:33 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
> Great news - happy to provide more input and feedback into the new
> tools/APIs when you get to that. I'd guess that Danno's probably got some
> good input for that side of it too - would be great to keep the
> conversations open and on this mailing list.
> 
> For my money, I'd vote for only show stopper bugs getting fixed on the
> existing packager code base, and you focus on getting it all cleaned up and
> working nice and a better pattern for contributions in place. That could
> allow us to contribute more and stop you churning endlessly on a backlog of
> bugs.
> 
> Cheers,
> Dan
> 
> 
> On Thu, Jun 6, 2013 at 1:21 AM, Mark Howe <mark.howe at oracle.com> wrote:
> 
> > I actually spent at least half my time on the packager the last two weeks
> > - woo hoo :). Still have other priorities but am finding time for the
> > packager. Working on a few critical packager bugs right now. Then later
> > this week going to finally get Danno's patches in. There are a lot of
> > packager bugs in the backlog. Once some of that backlog is cleared up I am
> > going to do some refactoring, really want to make the code  simpler,
> > cleaner and more obvious - and subsequently easier to contribute to.
> >
> > Cheers
> >
> >
> > On Jun 5, 2013, at 5:14 AM, Daniel Zwolenski <zonski at gmail.com> wrote:
> >
> > > Thanks Mark. If the user sets a preloader in the plugin I'm going to
> > pass that same class to the jar and to the native bundle. I guess people
> > will complain to me if that doesn't work and I'll point them your way.
> > >
> > > Are they ever going to let you do some packager stuff? I gave up waiting
> > for the revolution and rebuilt the maven plugin to be less crap than it was
> > but its the underlying packaging tools that need the rewrite if JFX is ever
> > going to have a decent deployment option.
> > >
> > > On 05/06/2013, at 3:58 AM, Mark Howe <mark.howe at oracle.com> wrote:
> > >
> > >> It should be the one within the bundle otherwise deploying an app
> > bundle won't work. If you find otherwise please create an issue.
> > >>
> > >>
> > >> Cheers
> > >> Mark
> > >>
> > >> On May 29, 2013, at 6:51 AM, Scott Palmer <swpalmer at gmail.com> wrote:
> > >>
> > >>> I think native bundles should use the preloader contained within.  I
> > use
> > >>> the Preloader to implement a splash screen since my app takes a long
> > time
> > >>> to start up, even though all the jars are already "downloaded".
> > >>>
> > >>>
> > >>> On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski <zonski at gmail.com>
> > wrote:
> > >>>
> > >>>> The jfx packaging tools allow pre-loaders to be set. I don't use them
> > but
> > >>>> people using the maven plugin want them.
> > >>>>
> > >>>> It looks like you can set a preloader for both jars and for bundles
> > (web,
> > >>>> native). When building the bundles however they include the jar in
> > them. So
> > >>>> we end up with both the bundle, and the jar within the bundle,
> > getting the
> > >>>> preloader set.
> > >>>>
> > >>>> Does anyone know what will or should happen in this case? Does one
> > >>>> preloader take precedence and the other is ignored, or are both used
> > at
> > >>>> different times and I should allow the user to set a different jar
> > >>>> preloader to the bundle one, or is this setup invalid and I should
> > actually
> > >>>> not pass the preloader setting to one or the other in this case?
> > >>>>
> > >>>> Not using Preloaders myself and with the packaging tool code being a
> > >>>> complete mess, it would be good to know the expectations here so I can
> > >>>> properly support the users wanting this.
> > >>>>
> > >>>> Cheers
> > >>>> Dan
> > >>
> >
> >
>