564023 - optional targetApplications attribute in package.json

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, enhancement, P2)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: optional targetApplications attribute in package.json

hacking a bit on rdf.py and app-extension/install.rdf I've prototyped
support for an optional targetApplications attribute
into the package.json.

right now targetApplications would be used only during xpi generation,
during testing (cfx test) and running (cfx run) app-template will be
targeted to xulrunner ([e-mail] with min 1.9 and max 1.9.*)

Ex:
{
   "id": "[e-mail]",
   "name": "example",
   "fullName": "My Example",
   "description": "example description",
   "homepage": "http://alcacoop.it",
   "author": "Luca Greco (http://ubik.cc/) <[e-mail]>",
   "version": "0.0.7",
   "license": "MPL 1.1/GPL 2.0/LGPL 2.1",
   "dependencies": ["jetpack-core"],
   "targetApplications": [
      { "name": "fennec", "min": "1.0", "max": "1.1.*" },
      { "name": "firefox", "min": "3.5", "max": "3.7.*" }
   ]
}

Comment 1

[Atul Varma [:atul]]

Thanks for the patch!

One of the things that would be nice to have is for 'cfx test' and 'cfx run' to work as close to 'cfx xpi' as possible--this way bugs can be seen at development/testing time rather than when an XPI is generated.

Also, is there any way for an addon to say "I don't care what app runs this, so long as it's on Gecko 1.9.2 or later"?  Or a way for individual packages and/or modules to say that they only work on a particular version of Gecko and/or Firefox/Thunderbird/etc.?  This would make it possible, for instance, for cfx to automatically figure out what versions of what apps an addon will be compatible with instead of having to burden the developer with this material.

At the very least, it would be nice if targetApplications were specifiable on a per-package basis, so that cfx could raise a warning if it said it was e.g. compatible with Firefox 3.6+ while a dependency said it only worked with Thunderbird 3.

What do you think?

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to comment #1)
> Thanks for the patch!

You welcome ;-)
 
> One of the things that would be nice to have is for 'cfx test' and 'cfx run' to
> work as close to 'cfx xpi' as possible--this way bugs can be seen at
> development/testing time rather than when an XPI is generated.

I agree, It would be possible to re-use install.rdf generation to create an install.rdf just before 'cfx test' and 'cfx run' will run mozrunner functions.
 
> Also, is there any way for an addon to say "I don't care what app runs this, so
> long as it's on Gecko 1.9.2 or later"?  Or a way for individual packages and/or
> modules to say that they only work on a particular version of Gecko and/or
> Firefox/Thunderbird/etc.?  This would make it possible, for instance, for cfx
> to automatically figure out what versions of what apps an addon will be
> compatible with instead of having to burden the developer with this material.

this is already possible using 'xulrunner' as targetApplication name, we could
rename it 'gecko' if it can be useful.


> At the very least, it would be nice if targetApplications were specifiable on a
> per-package basis, so that cfx could raise a warning if it said it was e.g.
> compatible with Firefox 3.6+ while a dependency said it only worked with
> Thunderbird 3.
> 
> What do you think?

This is definitely much more complicate but I'm sure it's possible, I will investigate where we should make any changes.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 443710 [details] [diff] [review]
optional targetApplications attribute in package.json

Unfortunately this patch no longer applies. :-(

Nevertheless, there may be a way to determine this information that doesn't require addon developers to manually specify it (which is not only extra work but is subject to error).

Mobile PM Thomas Arend and I chatted recently about how to support Firefox Mobile in the SDK, and we agreed that addons written using the SDK should automatically be compatible with both desktop and mobile versions of Firefox, without developers having to do anything special to make them so.

And the SDK includes a code analysis tool that builds a graph of modules used by an addon.

All of which suggests to me that the ideal solution would be for the SDK to include a manifest identifying the host application compatibility of individual modules.

Then the packager could automatically mark each addon as compatible with the set of host applications that are compatible with all the modules in the graph.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

This will be rendered redundant by the work on supporting Fennec natively.