Closed Bug 724276 Opened 10 years ago Closed 8 years ago

Add support to build XPI for other applications

Categories

(Add-on SDK Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: whimboo, Unassigned)

References

Details

Attachments

(1 file)

Right now the cfx command only allows to run and build XPIs for Firefox. There is no way to specify compatibility with other applications.

This kind of feature would be helpful to start experimenting with the support of the SDK for applications like Thunderbird.

I talked with Alex at FOSDEM and a probably good solution will be to add new entries to the package.json file, which then gets put into the install.rdf when building the XPI.

I will try to have a look at it.
We may have to split the following patch in multiple piece, 
but it highlights a WIP in order to bring back thunderbird support:
  https://github.com/ochameau/addon-sdk/tree/thunderbird
  https://github.com/ochameau/addon-sdk/compare/master...thunderbird

So the thunderbird support is not only about missing targetApplication in XPI.
There is some regressions introduced with the new module loader.
Alex, you will probably also wanna check bug 560716 which has been closed as wontfix a while ago due to lack of response. We should probably reopen?
Also we would have to update the RDFUpdate class in rdf.py so we also ship updates for the other applications.
Blocks: 724831
Attached file Pull request 341
Here is one way to handle "3rd party applications":
add an "application" attribute in package.json in order to control install.rdf file.
Matteo, you mentioned during FOSDEM event some concerns about this work as being irrelevant or useless regarding your upcoming work on module metadata. I still don't think it collide, in fact, I think both are complementary.
Depends on: 725323
Alex, I still think it collide: install.rdf will be generated based on the modules compatibility graph, without queries the "packages.json".

Here the module metadata bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=725409

As far as I understood from this bug the purpose is exactly the same, that's why I think they're overlapping.
Priority: -- → P3
As I pointed out in bug 725409 comment 3, mainly on last item.
I'm not convinced that module metadata will properly handle all cases,
so that having a way to override install.rdf may still be usefull
in order to :
 - specify a custom application id, or,
 - go off road and specify custom compatibility ranges,
 - handle edge cases when module metadata isn't precise enough.

So I still think:
1/ something similar will be needed, even, with advanced module metadata feature implemented.
2/ it will unlock multiple people to start hacking with the SDK, now.
Priority: P3 → --
Priority: -- → P3
I'm not sure why you saying that module metadata can't handle these cases you listed. They actually cover them as well – or, at least, they should be covered: the compatibility graph is made for this purpose.

If you think there is some specific case the compatibility graph and module metadata doesn't cover, then we should modify the module metadata proposal in order to cover it.

I agreed we need to provide this functionality so the community can start hacking with SDK, I was always pushing SDK for Thunderbird. That's because module metadata has a high priority, they have to be defined and landed as soon as possible.

I don't think that land this addition to packages.json and the module metadata immediately after is a good idea: they are designed to do mostly the same, so we could end up in racing condition. Also, developers could be confused: we already land too many things that actually trying to solve same problems, and then we're now spending effort to roll them back, and teaching to the community which one they have to use.
Assignee: nobody → zer0
(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #8)
> I agreed we need to provide this functionality so the community can start
> hacking with SDK, I was always pushing SDK for Thunderbird. That's because
> module metadata has a high priority, they have to be defined and landed as
> soon as possible.

Mark, Might some of our Thunderbird addon fans be interested in hacking at this?

And do we have anything specific/important waiting on this - beyond something for the average addon author?  Henrik tells me we need this to have memchaser addon work in Thunderbird. ref: https://github.com/mozilla/memchaser/issues/38
Flags: needinfo?(mbanner)
Just to update everyone is interested: I'm completing the bug 725409; I'm hoping to land it in the next days. Then, I'm going to fix this bug.
(In reply to Wayne Mery (:wsmwk) from comment #9)
> (In reply to Matteo Ferretti [:matteo] [:zer0] from comment #8)
> > I agreed we need to provide this functionality so the community can start
> > hacking with SDK, I was always pushing SDK for Thunderbird. That's because
> > module metadata has a high priority, they have to be defined and landed as
> > soon as possible.
> 
> Mark, Might some of our Thunderbird addon fans be interested in hacking at
> this?

Yes, I suspect they might.

> And do we have anything specific/important waiting on this - beyond
> something for the average addon author?

I guess the main things are for someone to take the lead on getting relevant parts of the existing sdk working, and then looking to expand what is necessary.
Flags: needinfo?(mbanner)
Mark, Wayne, I'm available for any kind of help you could need to makes SDK modules working on Thunderbird; so let me know in case!
I happily take this bug if it's free, and there is somebody to help me what to implement. :)
Duplicate of this bug: 892621
Due to bug 915376, the problem here is flipped, those other applications will have to support Jetpack instead, hopefully they pull from m-c..

We can probably won't fix this now.
Priority: P3 → --
So, how it will works, then? I mean if the devs wants to create an add-on that will works for both Firefox and Thunderbird, or Firefox and Fennec, or just Fennec?
(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #16)
> So, how it will works, then? I mean if the devs wants to create an add-on
> that will works for both Firefox and Thunderbird, or Firefox and Fennec, or
> just Fennec?

Devs will add `{ "engines": { "thunderbird": ">25" } }` to their package.json, and the rest is up to Thunderbird.
Cool thanks, so nothing is changed on that side.
When you mean "up to Thunderbird" it means it has just to pull from m-c, right?
Dave, shall we close this bug then?
Or we should leave it open and leave it depends by the Native Jetpack?
I think we should close it, and maybe open specific bug for those platform that should support jetpack.
Assignee: zer0 → nobody
Flags: needinfo?(dtownsend+bugmail)
Yeah this is a "going to be fixed by a different approach" bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(dtownsend+bugmail)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.