Preloaders

[Danno Ferrin]

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