Packaging Application Metadata

[Mark Fortner]

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
>