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.h...@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 <zon...@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.h...@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 <swpal...@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 <zon...@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 > >> > >
