Packaging Application Metadata

Tue Apr 9 11:11:17 PDT 2013

Cross platform assembly on a single platform is a goal for the deployment
team (http://javafx-jira.kenai.com/browse/RT-22994). From what I have seen,
everyone agrees it is a very highly desirable thing to have. This is not
easy however. There are both technical and legal issues.

Technical limits include things like wix only running on windows and
similar problems with mac assembly tools requiring mac OS. i.e. the
libraries to do this stuff are not cross-platform.

Creating custom libraries ourselves to do it that are cross platform is a
possibility but a heck of a lot of work (coming back to the limited
resources issues). Here we hit the legal issues however (e.g. MSI is a
proprietry format?). I haven't looked deep enough to know exactly how bad
these are but I have seen signs of problems here.

In short it may not actually be possible and if it is, it is very hard.

I believe the deployment guys were hoping (time permitting) to investigate
more on this sort of stuff over the last couple of months (I've been mostly
offline so not sure the latest news). I've cc'd Mark and Chris in from the
deployment team, maybe they can update us on any recent developments and
directions?

As an aside, I kind of feel we might be better stepping back and coming at
it from another direction rather than killing the limited resources we have
on trying to solve this one. Some alternate/lateral thinking options
include (my ideas only, not sanctioned by Oracle in any way, shape or form):

*1) The Farm*

A hosted service that people can submit their code to and this runs the
builds on virtual machines for each OS in the background and gives you back
you're requested bundles (or bonus points: submit it directly to the
appropriate app store if desired).

Obviously a lot of setup and ongoing hosting/bandwidth costs here (I don't
believe Oracle are considering this but I am just guessing and have no more
info than you) plus legal issues to work out (make sure code is protected,
etc).

A big player would be needed to host this and they'd need a reason to
justify the costs - possibly a fee for service or membership based (similar
to app stores). Not sure if there's enough incentive for anyone to take
this on?

*2) App Stores*

These are basically distribution mechanisms, and offer features on par or
better than webstart/JNLP. Building for these seems fairly open (just by
luck) using simplish, non-propriatry models (except the newer WinRT stuff
but it's got bigger problems than just deployment). If we focused purely on
app stores as our primary deployment mechanism we could *probably (*stress
that word as more investigation needed!) achieve cross-platform builds.

One problem with this approach is that there isn´t actually a good app
store for Windows 7 and below. There's some odd ones we could target (like
http://socialtimes.com/yes-finally-an-app-store-for-windows-7-say-what-yep-for-netbooks_b4626)
but not sure how well they work.

Alternatively there is also the option to build a 'Java App Store' that
required the user to first install a local app store client (for their OS).
The need for the user to install a client is not as nice as the OS specific
apps stores, but it could tie us over for Windows 7, until Windows 8 and
its app store establishes itself properly.

This is basically webstart/JNLP but instead of the JRE being the local
client as it is with JNLP (big, horrible install; can't manage multiple JRE
versions; forced auto updating of system wide JRE) we build our own client.
Small, light, clean and capable of managing numerous local JREs (i.e. my
app runs 1.7 yours runs 1.8, etc) by just unzipping them locally into
private directories (i.e. don't install them, just use them much the same
as the JFX native bundler uses the JRE now).

The code would not be that hard to write (I half did something similar when
mocking up auto updating for native installers a few months back). We'd
need zips of the JREs though, so they could be downloaded. So far Oracle
hasn't been keen on doing this (
https://javafx-jira.kenai.com/browse/RT-22964). If this was a community
effort only, OpenJRE could be zipped I imagine and we could use that
instead of Oracle's if we had to.

The actual host could be anyone, a bit like Maven repositories. So you
could host your own app store or some big player (e.g. Oracle) could host
an official one. That's just details though at that stage.

On Sun, Apr 7, 2013 at 5:44 PM, Mark Fortner <phidias51 at gmail.com> wrote:

> One thing that I've seen touched on in this conversation is the issue of
> universal (cross-platform) packaging vs platform-specific packaging. Like a
> lot of Java developers, the main reason I was attracted to Java in the
> first place was the promise of WORA. Even though I  work on Mac OS X and
> Linux boxes, everything still works when I deploy to Windows. I still like
> and use double-clickable jars and web start for that reason. I don't mind
> using packaging tools that shift the bits and bobs around for a particular
> platform, and willing use Daniel's maven plugin and other maven plugins for
> that purpose. But I'm not going to go out and buy Windows and Windows
> development tools just to make a Windows specific version of an app, and I
> think a lot of developers probably have similar feelings about their own
> platforms.
>
> What I'd like to see come out of these efforts with the packaging team is a
> simple tool that fits with my build process (maven/gradle), that at a
> minimum results in an executable jar.
>
> I'd like it if the JRE knew what to do with the metadata that we give it in
> the context to which it's deployed. For example, if I run the app on a Mac,
> the top-level menu bar should display my app name not "java". If I specify
> a particular menu item to be used for preferences, this the menu item
> should appear as "Preferences" and use the appropriate shortcut and appear
> in the appropriate location on the menu bar. Same thing with the About
> menu.   The JRE should know what to do with a dock icon, and desktop icon
> and splash screen.
>
> I'd like not to have to build shaded jars or uber jars. It would be nice to
> be able to point to dependencies in a local lib directory, or something
> that's the user equivalent of an .m2 repository directory where version
> controlled jars would be kept.
>
> I'd like a pluggable mechanism for resolving dependencies. This would make
> for smaller downloads and updates and I would be able to specify that an
> app should resolve its dependencies against the internal maven/
> Artifactory/Archiva repo if the app is being deployed internally.
>
> Updates should be deployable via off the shelf Tomcat or Glassfish without
> any additional config. The JRE should be able to detect if there is a later
> version of my app (in whatever home repo it resides in) and ask the user if
> they want to use it.
>
> The underlying philosophy should always be to make the default way simple
> to do, while always allowing for (and never preventing) more complex
> platform-specific solutions to be made. When in doubt always use Occam's
> Razor as your guide.
>
> Mark
> On Mar 27, 2013 4:49 PM, "Danno Ferrin" <danno.ferrin at shemnon.com> wrote:
>
> > How woud this XML descriptor be consumed?  As plain old text?
> >
> > This may be an EJB 1.0 throwback, but I would prefer the interface be via
> > Java objects, like the BundleParams.  Perhaps we could add on a
> > setProperty(String, Object) method that would be able to stash info not
> > exposed via the getters and setters.  Perhaps each packager class could
> > have it's own BundleParams class exposing.
> >
> > Another request is that the platform specific values don't just come from
> > the generic values.  Falling back to a shared value is fine, but there
> are
> > some overloaded values.  For example, appID needs to be a reverse DNS
> style
> > name on apple, and a GUID on windows.  And category has to come from a
> > limited set on apple, and different limited set for linux, and (if we
> ever
> > get WinRT Java) yet a different set for windows.  So appStoreCategory,
> > rpmCategory, debCategory, and win8Category could all fall back to
> category.
> >
> > Finally, perhaps the platform specific BundleParam could all be backed by
> > a Map instead of fields, and the getters would express the fallbacks
> while
> > the setters go to the most specific value.  That way a build tool could
> > read the descriptor in it's own way and push it into a hash that can be
> > re-used per platform.
> >
> > (I'll cross post this to the JIRA)
> >
> > On Tue, Mar 26, 2013 at 2:48 PM, Mark Fortner <phidias51 at gmail.com>
> wrote:
> >
> >> So to sum up, for the sake of the JIRA issue, we're asking for:
> >>
> >> A single cross-platform application packaging specification that would:
> >>
> >>    - Allow the application developer to specify common cross-platform
> >>    attributes (i.e. application name, description, splashscreen,
> >> dock/desktop
> >>    icon, app store categories, etc). *-- Need as complete a list as
> >>    possible here.*
> >>
> >>    "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)."[John Smith]
> >>
> >>
> >>    We might also include support for Mac OS X dock menus and some of the
> >>    other features mentioned here:
> >>
> >>
> https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/00-Intro/JavaDevelopment.html#//apple_ref/doc/uid/TP40001911-SW1
> >>
> >>    - Since dock/desktop icons may be platform-specific, the user should
> be
> >>    able to specify a PNG or JPG, and the packaging tool should handle
> the
> >>    conversion of those resources to platform-specific file types.
> (Apache
> >>    Commons Imaging seems to support most of the formats that Danno
> >> mentioned).
> >>
> >>    - The packaging tool should be able to generate platform-specific
> >>    artifacts from the specification, including plists for Mac apps,
> >> appx's for
> >>    Windows apps, etc.
> >>
> >>    - I'm probably in the minority here, but I would like to be able to
> >>    generate JNLP from the specification. For this I would like to be
> able
> >> to
> >>    specify a Maven repo, where dependencies are stored, in addition to
> >> being
> >>    able to specify single JARs to be served up from a web server.  This
> >> would
> >>    let me serve *myapp.jar* from my web server, and all of it's
> >>    dependencies from whatever internal/external repos they're stored in.
> >>
> >>    - Platform-specific attributes may be specified (stealing again from
> >>    Danno's post: "such as Mac app ids, windows GUIDs, gatekeeper
> sigining
> >>    keys, entitlements, etc.").
> >>
> >>
> >> Since we may not know apriori what platforms the application is being
> >> built
> >> for, the specification should permit the app developer to specify
> >> attributes as generically as possible, and the packaging tools should
> >> handle any conversion, or placement of application resources into a
> >> directory structure as needed.
> >>
> >> I wonder if it might be possible to define a common set of attributes
> and
> >> have a delegateable set of platform-specific attributes?  You could have
> >> separate platform-specific packagers that would parse and deal with
> their
> >> attributes.  If you need to support a new platform, you plug-in the
> >> packager for it. Something like this:
> >>
> >> <application>
> >>   <platform type="java" supported-java-versions="" app-version="">
> >>    <name language="en">My App</name>
> >>    <description language="en">...</description>
> >>
> >>    <icon type="dock" src=""/>
> >>    <icon type="desktop" src=""/>
> >>    <libraries> ... similar to what you see in JNLP with
> >> platform-independent and platform-dependent lib references
> >>     </libraries>
> >>     <security> ... a list of the privileges the app asks for (although
> it
> >> might be better for the packager to determine this).
> >>     </security>
> >>
> >> <platform type="deb">
> >>   ... any non-redudant, platform-specific attributes go here
> >> </platform>
> >> <platform type="windows" version="">
> >>   ... support attributes for specific versions of the OS
> >> </platform>
> >> </application>
> >>
> >> Feel free to edit as needed.  And be as specific as possible. This will
> >> make it easier for whoever gets assigned the task.  Thanks to Mark Howe
> >> for
> >> creating the issue.  https://javafx-jira.kenai.com/browse/RT-29229
> >>
> >> Cheers,
> >>
> >> Mark
> >>
> >>
> >>
> >> On Mon, Mar 25, 2013 at 1:42 PM, Richard Bair <richard.bair at oracle.com
> >> >wrote:
> >>
> >> > >> 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.
> >> > >
> >> > > I think that is the right way to go.  Start fresh and it should be
> >> > possible to generate the legacy format information for JNLP or Applets
> >> from
> >> > the new format.
> >> > >
> >> > > It would be nice for icons to have the tool do the conversion from
> >> plain
> >> > old image files (32-bit PNG).  Supply various size and let the tool
> >> > generate any missing sizes that might be needed so a reasonable .ico
> or
> >> > .icns file is created for both Windows and Mac.
> >> >
> >> > That is my preference as well. If you can supply the right stuff
> >> > specially, then we will use it, but to the extent reasonable we should
> >> just
> >> > automatically handle a lot of these more annoying differences.
> >> >
> >> > Richard
> >>
> >
> >
> >
> > --
> > 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
> >
>