Packaging Application Metadata

[John Smith]

As an alternative (or supplement to jnlp), perhaps something like the appx format could be used.

http://msdn.microsoft.com/en-us/library/windows/apps/br211475.aspx (simple appx file).
http://msdn.microsoft.com/en-us/library/windows/apps/br211472.aspx (appx schema).
http://en.wikipedia.org/wiki/Open_Packaging_Conventions (appx is based on open packaging conventions).

If you want something deployable via Windows Store, you will need to generate appx based packaging anyway.

The appx stuff has better definition than jnlp around OS integration points and awareness of more modern (or old but oft used and not in jnlp) application concepts: 
 - file type specifiers (ability to specify that the app is associated with a given os file type extension).
 - localizable app name strings (e.g. an Italian name for an app as well as an English one).
 - ability to override default load/save dialogs with custom implementations.
 - ability to hook into notification systems (e.g toast pop-ups).
 - ability to specify app types as long running services
 - set desired initial orientation (e.g. landscape, portrait).
 - ability to differentiate between touch capable devices and provide info that an app requires touch support.
 - ability to customize device lock screens, with application specific data.
 - fine grained auth info (e.g. specify app needs to make use of a camera use, microphone, gps services, etc).

The format seems pretty easy to understand and just references resources like splash images and application icons that are defined at relative locations in a zip file.
An issue is that it is too broad for JavaFX as JavaFX does not support many of those features (and probably many of them it never will).
However you could define just a subset of those features that you do support.

JavaFX also currently needs to deal with the JNLP style deployment legacy, so offering an appx style packaging would be an additional thing required in addition to JNLP.
Also, an appx based approach may end up being pretty Microsoft specific, and you may want something different for on OS X deployment, Linux distribution etc. 

Even now, the way that you specify icons for a self-contained application is different from the way you do it in a JNLP and it differs across target platforms as Danno points out.

------------------------------

What *may* be desirable is some kind of high level tool and system which can map some common definition of the metadata (app name, logo, description, file type extensions, residency and notification requirements, resources and permissions required, etc) to platform specific (e.g. OS) and deployment model specific (e.g. JNLP/MSI/DEB/APPX/Windows Store, etc).  Such a system would always ending up being either less functional than a pure use of native packaging tools and formats, or a leaky abstraction which might expose stuff like Windows specific data and fields.

It's not clear to me though how application metadata definition would best be accomplished.  

Should 

(a) JavaFX define it's own metadata for metdata format such that a developer just specifies data in one format and deployment tools (e.g. javafxpackager, javafx maven/gradle plugins) then generate the metdata for a given target platform and deployment model?

OR 

(b) JavaFX not worry about platform specific metadata (outside of support for existing JNLP based solutions) and say that creation of the metadata to support a given deployment model is up to the application developer and varies depending upon the deployment model chosen (similar to the way that a customized self-contained application packaging would work today)?

-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Danno Ferrin
Sent: Monday, March 25, 2013 11:09 AM
To: Mark Fortner
Cc: openjfx-dev at openjdk.java.net
Subject: Re: Packaging Application Metadata

Of course this discussion starts while I am away on spring break.

The current way icons are handled are per-platform.  Windows wants a ICO and BMP, mac wants an ICNS, and linux wants a PNG.  And the 'location' for them is in the classpath under a package 'platform/windows', 'platform/mac', and 'platform/linux.'  That's not the worst.  The names of the icons are based upon the name of the application, so it would be 'platform/mac/My Awesome App.icns'.

What I am doing in the gradle plugin for JavaFX is to have a separate 'src/deploy/package' source fork (like src/main/java and src/test/java) that contains the platform specific resources.

Furthermore, I take the root of that directory to store 'generic' icons that the plugin converts to the needed formats, files of the form 'shortcut*.png' become the dock and app icons, 'volume*.png' for the mac dmg volume icon, and 'setup*' for the windows installer wizard top corner icon.  These are globs so that multiple icons can be grouped together into multi-resolution icons.

Here is a sample for the brickbreaker demo:
https://bitbucket.org/shemnon/javafx-gradle/src/a54f3fc76bdd/samples/brickbreaker/src/deploy/package?at=master

If there is any change, at least we need to get the resource snooping off of the classpath and be able to pass in one or more root directories that the packager can inspect rather than using the classpath of invocation, which is at best archaic for modern build tools.

The real work comes in the per-platform monkeying of the icon formats.  But there are some per platform issues that cannot be easily unified and will have to stay per-platform, such as Mac app ids, windows GUIDs, gatekeeper sigining keys, entitlements, etc.

On Mon, Mar 25, 2013 at 11:29 AM, Mark Fortner <phidias51 at gmail.com> wrote:

> Hi Daniel,
> Thought I would jibber-jabber first on the list till there's some sort 
> consensus before filing an issue. :-)
>
> My earlier thought was that JNLP could serve as a starting point for 
> discussions, since people might already be familiar with it.
>
> Could you elaborate on this remark a bit: "[JNLP] has a lot of legacy 
> that complicates areas that don't need it (e.g. native packaging)". 
> What legacy are you referring to?
>
> I'm probably in the minority as far as webstart is concerned, but I've 
> found it useful in the past as a means of keeping desktop apps in a 
> company up-to-date.  I haven't seen any cross-platform approach that 
> comes close to being able to solve this problem (except perhaps Marimba back in the day).
>  We don't really have a corporate Java App Store, where you could 
> easily register an app and keep it up to date.  There are some 
> platform-specific solutions in the Winblows world, but I haven't seen 
> anything that works everywhere.
>
> As for icon formats, I was thinking that we could register PNGs in the 
> project, and the packaging tool/maven plugin could handle any 
> platform-specific conversions.
>
> Cheers,
>
> Mark
>
> PS Welcome back from vacation!
>
>
>
> On Mon, Mar 25, 2013 at 8:06 AM, Daniel Zwolenski <zonski at gmail.com>
> wrote:
>
> > I'd recommend creating a JIRA for this as the deployment guys are
> > (hopefully) working on improvements in this area. They may have 
> > inclinations in this direction but I'd be surprised if there was 
> > anything solid in the pipeline or on the horizon. There's a 
> > 'deployment' category
> or
> > something like that where it should end up with the right people.
> >
> > I looked at JNLP as a basis for this sort of stuff but it has a lot 
> > of legacy that complicates areas that don't need it (e.g. native packaging).
> > I'd suggest (and have suggested in some long emails in the past) an 
> > application profile of some kind that can be used as the main 
> > deployment descriptor for Java apps regardless of how it gets 
> > deployed and may also form the base of Auto Updating.
> >
> > Having said that, I'd personally leave JNLP and Applet completely 
> > alone and only look at the newer deployment options for this sort of stuff.
> They
> > are likely to be unusable options before too long as browsers stop
> plugins
> > and OS's lock into app stores. The horrid legacy of JNLP and Applet
> hinder
> > all the new options (app stores, native installers, mobile, etc) 
> > from evolving quickly. Some people will likely object to that 
> > though, just my opinion.
> >
> > Also be aware there are complications with things like icon formats 
> > (need to convert between .ico and .png, etc), image sizes, allowed 
> > characters
> and
> > lengths in names (e.g. wix supports different things to mac, etc), 
> > licencing information needed for different platforms (e.g. app 
> > stores), etc, etc. So standardising will be quite a complicated 
> > process that would likely take a fair bit of time to nail down if 
> > work was started on it. As usual don't pin your hopes on any good 
> > solution arriving soon (Java8
> would
> > be extremely optimistic I imagine).
> >
> >
> >
> >
> > On Mon, Mar 25, 2013 at 9:44 AM, Mark Fortner <phidias51 at gmail.com>
> wrote:
> >
> >> I've been wondering if there were any plans to standardize 
> >> packaging metadata?  It strikes me that we should be able to 
> >> specify dock and desktop icons, splashscreens, application names, 
> >> OS-specific packaging
> properties
> >> (like the ones used in Mac OS X) and dependencies in a single place 
> >> that can be used by both an application packaging tool, and on 
> >> application startup.  The JNLP file has most of these elements 
> >> already and could
> serve
> >> as a useful starting point.
> >>
> >> Any thoughts?
> >>
> >> Mark
> >>
> >
> >
>



--
There is nothing that will hold me back.  I know who I am....
I remember wher I came from, and I feel stronger for knowing.
Zane, Ninja of Ice.  Ninjago S01E07