Packaging Application Metadata

[Danno Ferrin]

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