This is needed to support FlightDeck integration.
This would be useful for SDK users in addition to FlightDeck developers.
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Summary: Add documentation to 0.1 explaining how to build XPIs automatically with cfx → Add documentation explaining how to build XPIs automatically with cfx
Target Milestone: -- → 0.2
This bug is somewhat related to Bug 553435, which mentions that 'cfx xpi' can be used to build an XPI. I was planning on holding out on more details about the use of this until we add XPI creation to the tutorial--right now there's no need to do such a thing, however, since we don't yet have any APIs that can be used to make useful extensions.
Noelle: is this something you can take on? Ideally, we'd have this in for 0.3, where we plan to have some high-level APIs (but even if we didn't, developers can still use the SDK to create extensions with their own high-level APIs, so it would be good for them to know that they can package them easily).
Target Milestone: 0.2 → 0.3
Note that we already have documentation on how XPIs are created, even though we don't have formal documentation on 'cfx xpi': https://jetpack.mozillalabs.com/sdk/0.2/docs/#guide/xpi
Target Milestone: 0.3 → 0.2
Atul might be able to tackle this and get it done today in time for the 0.3 code freeze, not sure yet. Leaving it unassigned pending further clarity. In the meantime, if someone else wants to take it on, please do!
Assignee: nobody → dietrich
Version: unspecified → Trunk
per Atul: "we wanted to re-vamp the third part of the tutorial to have you make an addon that e.g. modifies a context menu or something, instead of 'hello world' to console" referring to: https://jetpack.mozillalabs.com/sdk/0.2/docs/#guide/programs
Created attachment 440388 [details] [diff] [review] v1 Changes the "Programs" page in the tutorial: - adds section for using jetpack-core libs - changes example code to use the new context-menu module - adds section for generating an xpi - changes the run section to load the xpi The "run" section uses mozrunner for the moment. I've filed bug 560743 to get cfx to support mozrunner's -a argument. Once that's available, we should change the tutorial so that it uses cfx all the way through.
Attachment #440388 - Flags: feedback?(myk)
Comment on attachment 440388 [details] [diff] [review] v1 This looks great and is exactly the right approach. feedback++! Some review notes below... >+### Adding Your Code ### > > If a module called `main` exists in your package and it exports a > function called `main`, the function will be called as soon as your >-program is activated. By "activated", we mean that either a containing >+program is activated. By "activated", we mean that either a host > application such as Firefox or Thunderbird has enabled your program as > an extension, or that your program is itself a standalone application. Here it would be useful to say that the forthcoming example will demonstrate an extension. > You'll note that the code above also uses a global object called `console`. > This is a global accessible by any Jetpack module and is very useful > for debugging. Your new version of the code doesn't actually use console! So this is no longer accurate. Perhaps you could throw in a random console.log (f.e. logging the link text that is going to be searched)? >+### Packaging It ### In between the Logging and Packaging It sections, it seems like it would be good to have a section called Running It that describes how you can run your extension by doing |cfx run -a firefox|, which is easier and faster than doing |cfx xpi; mozrunner -a test.xpi|. Then, I would call the last section, which is currently called Running It, something like Checking the Package, explaining that this is the last step to perform before uploading the package to AMO. And finally, I'd add a section called something like Distributing It saying that the last step is to upload the package to AMO (perhaps with a note suggesting that we're looking for ways to automate this step as well?). I.e. the flow would be: first explain how to test your extension by running it, then explain how to package it, after that explain how to make sure the package works as expected, and finally describe distributing the package via AMO. My one hesitancy with this recommendation is that in theory it shouldn't be necessary to check the package if the extension worked correctly when you ran it with |cfx run|, since the packaging is performed by the tool, and in theory the tool should create a package that performs exactly the same as the extension does when run via |cfx run|. Nevertheless, I expect that it's a good final check to do. I suppose one could then leave out the |cfx run| step, since it's somewhat redundant with this step, although trying it out before packaging somehow seems like the right order in which to do those things (but maybe my brain is stuck in traditional extension development land). >+Your program is packaged like any other extension for a Mozilla-based >+application, as an XPI file. The Jetpack SDK simplifies the packaging >+process by generating this file for you. >+ >+To package your program as an XPI, navigate to the root of your package Nit: XPI is traditionally pronounced like "zippy" and thus takes the "a" version of the indefinite article! > ## To Be Continued... ## > > Right now, the Jetpack SDK is at an early stage of > development. There's not too much to show. But be on the lookout for > upcoming versions of the SDK, which will continue this tutorial and > show you how to build a useful Jetpack-based Firefox or Thunderbird > extension that you can distribute to your friends, foes, and family! This should be updated now that the tutorial does show you how to build a useful Jetpack-based Firefox extension that you can distribute to all sorts of social contacts!
Attachment #440388 - Flags: feedback?(myk) → feedback+
(In reply to comment #9) > My one hesitancy with this recommendation is that in theory it shouldn't be > necessary to check the package if the extension worked correctly when you ran > it with |cfx run|, since the packaging is performed by the tool, and in theory > the tool should create a package that performs exactly the same as the > extension does when run via |cfx run|. Yeah, this should really be the case; as a final step before distribution, it also might feel more "natural" or "real" to the developer to actually install the XPI manually in their own version of Firefox/Thunderbird/etc., to use it "in the wild" as it were. That's sort of a gut feeling though, not sure how to rationalize it. :P > although trying it out before packaging somehow seems like the right > order in which to do those things (but maybe my brain is stuck in traditional > extension development land). Yes, support for running extensions without going through the packaging step was an intentional design feature of the toolchain: not having to package things means a faster code-test cycle, and in some special cases, such as where your extension displays a "packaged" file in a browser tab, it means that you can make edits to parts of your code and see their effects without having to re-package anything at all (e.g., in the aforementioned example, you can just reload the page in the browser tab). > This should be updated now that the tutorial does show you how to build a > useful Jetpack-based Firefox extension that you can distribute to all sorts of > social contacts! We should also probably point this out prominently in the release notes and other materials for the 0.3 SDK, since folks who have been following the SDK will be likely to think that they don't need to re-read a tutorial that they've already read. Dietrich filed bug 560666 suggesting that we have some sort of visual indication in the left sidebar for new modules--the same kind of thing for recently-modified tutorials/appendices could be nice too!
Thanks for the feedback, definitely makes more sense to show off the package-less install method of testing a package. This change probably removes the need for bug 560743. In the "checking your package" section, i'll put notes on using mozrunner or the tradition method using Firefox directly. New patch coming up.
Created attachment 440414 [details] [diff] [review] v2 All changes made, and code tested against the context menu module that was checked in.
Created attachment 440416 [details] [diff] [review] v2.1 typo fix (thx adw)
Comment on attachment 440416 [details] [diff] [review] v2.1 Looks great! r=myk The only minor nit I noticed was that one of the two instances of "an XPI" remains. I'll commit this patch shortly so it makes the freeze and fix that in the process.
Attachment #440416 - Flags: review?(myk) → review+
Fixed by changeset http://hg.mozilla.org/labs/jetpack-sdk/rev/7f362c854cfe.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
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
You need to log in before you can comment on or make changes to this bug.