Closed Bug 298498 Opened 19 years ago Closed 19 years ago

Allow extension XPIs to ship multiple independent extensions

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8beta4

People

(Reporter: benjamin, Assigned: robert.strong.bugs)

References

()

Details

Attachments

(1 file, 4 obsolete files)

Several extensions depend on common util extensions like JSlib. In addition to extension dependencies (bug 298497), it would be good to allow these extensions to come bundled with their dependencies (a multi-extension XPI). I'm not quite sure how this should be accomplished (subdirectories?, a new manifest format?).
Simplest would be a new install manifest format. Existing extension xpi's could be packaged into a single xpi with the new manifest and then installed all at the same time. Signing could be done on the top level xpi and we wouldn't concern ourselves with signing on the individual xpi's contained. It isn't fancy but it would get the job done and keeps the packaging process as simple as can be.
Robert, if you would like to write up a design proposal (on wiki.m.o perhaps?) that I can review, that would be great. I was just thinking of something like /extensions.list (contains a plaintext list of GUIDS) /{GUID1}/install.rdf /{GUID1}/all-those-other-files /{GUID2}/install.rdf /{GUID2}/all-those-other-files
I will write something up... it would be simpler and less error prone to just package up the xpi's insiide of another xpi instead of extracting them into their GUID dir's.
Attached patch work in progress (obsolete) — Splinter Review
This works... it just needs additional error handling and cleanup. Anyone have suggestions for the obvious bad names like MULTI_XPI, etc.? The format of the install manifest is available on the wiki http://wiki.mozilla.org/Extension_Manager:Multiple_Item_Packages
I kinda like multi_xpi, but I suppose you could use multi_item.
Attached patch better still (obsolete) — Splinter Review
No longer allows jar files to be a multi_xpi and adds some user notification when errors occur. em:name and em:version are needed in the install manifest to leverage existing user notification especially when installing by dropping the xpi into a extensions directory since that uses em:name in the xpinstall dialog. This is close to being done but I am unsure if a multi_xpi should support compatibility updates. If it does then em:id will also be required which wouldn't be such a bad thing as I see it.
Attachment #188751 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
I believe this is the ticket... the wiki contains notes as to why I decided to keep the format of the install manifest the same as for extensions.
Attachment #188888 - Flags: first-review?(benjamin)
Attachment #188888 - Attachment is obsolete: true
Attachment #188888 - Flags: first-review?(benjamin)
Attached patch slightly cleaner (obsolete) — Splinter Review
Moved one multi_xpi specific user notification that wasn't in installMultiXPI into it.
Attachment #188824 - Attachment is obsolete: true
Attachment #188893 - Flags: first-review?(benjamin)
Comment on attachment 188893 [details] [diff] [review] slightly cleaner You don't need to rev the iid of nsIExtensionManager if you're only adding a constant, it doesn't affect the interface vtable. In extensions.properties, change "Multiple Item XPI" to "Multiple Extension Package"
Attachment #188893 - Flags: first-review?(benjamin) → first-review+
Attached patch patchSplinter Review
Addresses comments... thanks for the review! Are you ok with this landing after 1.1a2 is released?
Attachment #188893 - Attachment is obsolete: true
Attachment #189018 - Flags: first-review?(benjamin)
Comment on attachment 189018 [details] [diff] [review] patch Yes, this will get 1.8b4+ whenever we get b3 out the door.
Attachment #189018 - Flags: first-review?(benjamin)
Attachment #189018 - Flags: first-review+
Attachment #189018 - Flags: approval1.8b4?
Attachment #189018 - Flags: approval1.8b4? → approval1.8b4+
Whiteboard: [checkin needed][a+]
Checking in mozilla/toolkit/mozapps/extensions/public/nsIExtensionManager.idl; /cvsroot/mozilla/toolkit/mozapps/extensions/public/nsIExtensionManager.idl,v <-- nsIExtensionManager.idl new revision: 1.37; previous revision: 1.36 done Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in; /cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v <-- nsExtensionManager.js.in new revision: 1.125; previous revision: 1.124 done Checking in mozilla/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties; /cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties,v <-- extensions.properties new revision: 1.14; previous revision: 1.13 done
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta4
Whiteboard: [checkin needed][a+]
Hm, what happens if FooExt 0.5 is part of a multi-XPI, but the user already has FooExt 1.0? Unless I overlooked it in the patch, there is no special handling for this, so FooExt gets downgraded - which probably isn't what we want here...
This bug provided the base functionality and new bugs should be opened for additional functionality or if there is anything broken in the base functionality as described in the wiki.
It would be good to get semi-official documentation of this feature up at or linked to http://developer-test.mozilla.org/en/docs/Extension_Packaging
(In reply to comment #16) > It would be good to get semi-official documentation of this feature up at or > linked to http://developer-test.mozilla.org/en/docs/Extension_Packaging I added the following but my wiki skills are lacking for addiing it to the Official links http://developer-test.mozilla.org/en/docs/Multiple_Item_Packaging
Component: XRE Startup → Startup and Profile System
QA Contact: nobody → startup
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: