JFX build and deployment - squeaking wheel

Tue Nov 6 08:45:58 PST 2012

I agree that building app bundles from any platform for any other platform would be a huge win, as it would make it trivial for anybody to use. Some thoughts:

  - For DMG I thought it was basically an HFS formatted file? And I thought there were Java tools out there already for reading / writing to HFS. I doubt creating DMG's from any platform would be an insurmountable problem.

  - For .app, of course, this is pretty easy for us to do on any platform as it is just a specially named directory with various meta-data.

  - Sounds like appx isn't going to be too hard either

  - I am not sure about RPM and DEB, but I'd be shocked if those couldn't be produced from any arbitrary OS

  - WiX is probably going to be a bit of a pain in the neck. We can scope it down to make it less difficult, but writing a complete WiX parser / MSI producer is probably a big job and, I would guess, a moving target (if Microsoft is continuing to add features to it or support it, which I suspect is the case).

  - I don't have any knowledge on producing .exe files. Anybody?

It seems to me that at least the Mac / Linux side of the problem should be fairly straightforward. Unless you have to sign your .app, in which case it might be a little more cumbersome. Also the giving of entitlements to a Mac application might be another problem area? On the windows side I have less experience with native windows installer technology so I'm not sure how practical it is to create exe files or .msi installers based on WiX?

On Nov 5, 2012, at 3:22 PM, Daniel Zwolenski <zonski at gmail.com> wrote:

> Also very, very interesting. 
> 
> This format looks quite easy to work with and as far as I can see would allow for Windows apps to be built on other platforms (e.g. Linux). We should in theory just be able to include the JRE in the bundle and then call javaw.exe via the manifest. No native building necessary, just a sort of "zipping". 
> 
> I'm still digging but I can't see a way to pass command line params, so specifying "javaw.exe -jar myapp.jar" via the AppxManifest.xml might be problematic. Hopefully there is something there for this, but it wouldn't surprise me if MS didn't support this on purpose. 
> 
> An alternative might be to have a custom launcher.exe that reads a bundled app-profile file and then launches java.exe as a new process with the appropriate details, or a modified JRE that does the same thing but without starting a new process. Not sure if we'll run into the same legal restrictions as Mac store though with OpenJDK and GPL (probably) so might have to limit it to whatever can be done with the Oracle JRE. 
> 
> Ensemble in the Windows store maybe? I don't have a windows 8 machine yet though. 
> 
> Do we know if JFX will need/benefit-from any changes to work on Win8 or will the current Win implementation be the same used on Win8 going forward? 
> 
> 
> 
> 
> On Tue, Nov 6, 2012 at 9:32 AM, John Smith <John_Smith at symantec.com> wrote:
> > Is this what the new Windows Store uses as well?
> 
> No, Windows Store does not use MSI, it uses appx files and Open Packaging Conventions.
> 
> There is no installer, updater or uninstaller for the package, just some metadata which a store client can use to install, update or uninstall a component.
> appx is just like a zip file with a manifest, similar to a jar file.
> 
> Those interested, can see here for info:
>   http://msdn.microsoft.com/en-us/library/windows/desktop/hh464929.aspx App packages and deployment (Windows Store apps)
>   http://msdn.microsoft.com/en-us/library/windows/desktop/hh446767.aspx App packager (MakeAppx.exe) - kind of the Windows Store equivalent of javafxpackager.exe
>   http://msdn.microsoft.com/en-us/library/windows/desktop/hh446593%28v=vs.85%29.aspx Packaging, deployment, and query of Windows Store apps
> 
> -----Original Message-----
> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair
> Sent: Monday, November 05, 2012 12:58 PM
> To: Josh Marinacci
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: JFX build and deployment - squeaking wheel
> 
> I'm not sure, to be honest.
> 
> On Nov 3, 2012, at 11:08 AM, Josh Marinacci <joshua at marinacci.org> wrote:
> 
> > Interesting.  Is this what the new Windows Store uses as well?
> >
> > --
> > Josh Marinacci
> > joshondesign.com
> >
> > On Saturday, November 3, 2012 at 11:07 AM, Scott Palmer wrote:
> >
> >> Right. MSI is sort of an official MicroSoft Installer format. The
> >> .msi file is read by the built-in Windows installer APIs. Sort of
> >> like how .pkg is handled natively by OS X, and .rpm and .deb are
> >> handled natively by Linux distros. Exe installers could be anything,
> >> they just aren't the same. though often they are special
> >> bootstrappers tacked on to one or more MSI databases. MSI is a
> >> table-based description of the stuff to install. (It isn't
> >> particularly good mind you, it's just well supported by the Windows
> >> OS.)
> >>
> >> Scott
> >>
> >> On 2012-11-03, at 12:10 PM, Joshua Marinacci <joshua at marinacci.org> wrote:
> >>
> >>> Ah. So an MSI is not just another installer format? It has special
> >>> properties make it different than NSIS?
> >>>
> >>> Most likely sent from Planet Earth
> >>>
> >>> On Nov 3, 2012, at 6:45 AM, Richard Bair <richard.bair at oracle.com> wrote:
> >>>
> >>>>> I just tried using the AppBundler (the other one from Java.net) to create a Mac bundle with an embedded JRE and it worked pretty well. For Windows is an MSI file a requirement or could some other installer system work? I just found NSIS which can generate Windows installers from linux.
> >>>>
> >>>> The reason MSI is important is that for many large sites with IT departments, they don't want to have to go around from machine to machine manually installing software and, they don't trust users to be able to download and install software themselves (either by policy or by some means of enforcement). Giving the IT department an MSI allows them to remotely push updates / software onto the correct users machines according to whatever policies they've crafted in their business. Or remove the software when the time comes.
> >>>>
> >>>> Richard
> >
> 
> 