Packaging Application Metadata

[Danno Ferrin]

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