optional targetApplications attribute in package.json

RESOLVED INCOMPLETE

Status

P2
enhancement
RESOLVED INCOMPLETE
9 years ago
7 years ago

People

(Reporter: rpl, Unassigned)

Tracking

unspecified
Future

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Created attachment 443710 [details] [diff] [review]
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 (toolkit@mozilla.org with min 1.9 and max 1.9.*)

Ex:
{
   "id": "example@alcacoop.it",
   "name": "example",
   "fullName": "My Example",
   "description": "example description",
   "homepage": "http://alcacoop.it",
   "author": "Luca Greco (http://ubik.cc/) <luca.greco@alcacoop.it>",
   "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.*" }
   ]
}
(Reporter)

Updated

9 years ago
Attachment #443710 - Flags: review?(avarma)

Comment 1

9 years ago
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?
(Reporter)

Comment 2

9 years ago
(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.
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".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Version: Trunk → unspecified

Updated

8 years ago
Attachment #443710 - Flags: review?(avarma)
Attachment #443710 - Flags: review?(myk)
Priority: -- → P2
Target Milestone: --- → Future
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.
Attachment #443710 - Flags: review?(myk)
This will be rendered redundant by the work on supporting Fennec natively.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.