Using --retro mode creates an install.rdf that Firefox uses for all of it's metadata until the Addon Manager can natively read Jetpack's package.json. This should support all options available here:
https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/package_json

Import 0.0.2 of jetpack-id when mozilla-jetpack/jetpack-id/issues/2 fixed

When I run npm test this is run https://github.com/mozilla/jpm/blob/master/package.json#L10 and that does not work on windows.

I get an error that says:

`export` is not recognized as an internal or external command

This'll probably have several components to it, but a basic API for using this via node should be possible:

var jpm = require("jpm");
jpm.xpi("/path/to/dir").then(function (xpi) {})
jpm.run("/path/to/dir").then(function () {})

Similar to #5 which is having this work in an addon itself, but first got to get the API working and usable before we think about stripping down dependencies for use within an Addon.

If I have a xpi in my working directory, and I call jpm run (or test), this will create a new xpi that overwrites the one I already have in my directory, and then removes it after it's installed, effectively losing my previous xpi.

For cases where a xpi is generated as the byproduct of a task (run/test), then these should be created in a tmp folder, where they are subsequently removed.

Should create a ./lib/main file and a test/index file, with appropriate manifest settings
Example: https://gist.github.com/canuckistani/43e8ba6ea9f7245c75e6

At the moment we don't have way of exiting firefox with specific exit code (see bug 894697). CFX generates file
into which we write "OK" or "FAIL" before exiting firefox, I think it would be best if
we set ENV variable "JPM_EXIT_CODE" from test runner before exiting firefox,
which JPM could recognize as an exit code, until mentioned bug is fixed.

This is an example of why I'd like to keep the test options out of the package.json file, if we use a jetpack-test-options.json file then it is trivial to support old school add-ons.

Platofrm: Windows

Simply run jpm run or jpm xpi in a directory that doesn't have package.json. jpm will try to run or package, and the step that prints JPM info Creating XPI at ... will hang

might be fixed by #88?

When I do jpm run -b /Applications/FirefoxNightly.app/ with https://github.com/erikvold/markdown-viewer I get the following message logged:

JPM info Running undefined on Markdown Viewer

I'm not sure what the undefined is supposed to be atm, but this shouldn't happen.

JPM should pre-configure profile such that [email protected] preference is set to 1 if --stop-on-error flag is applied.

Looks like we're buffering output instead, when I run jpm --verbose run I should see console.* messages in the terminal in real time.

Gif:

https://dl.dropboxusercontent.com/u/1212936/buffered.gif

basically, this code should have the same output with JPM as it has with CFX:

let xx = require("@loader/options").metadata;

for (let k in xx) {
    console.log(k, ': ', xx[k]);
}

JPM should:

1. Identify add-on's using package.json/id if it is valid. If not it should
   raise an error and propose updated value. Note that CFX generates
   invalid package.json/id and then normalizes it by adding @jetpack.
2. If package.json/id isn't present (ideal case) add-on should be identified
   as "@" + package.json/name. That's should be an ID written to an
   install.rdf file. Note that package.json/id should not be added.

Test runner should not depend on allTestModules to be provided by CFX in order
to do it's job. Test runner should just iterate over test files and run tests on it's own.

At the moment CFX handles some localization tasks. JPM does not has that so add-ons with localization are going to fail. It looks like with Bug 935290 it should pretty much work.

STR:

1. create a jpm-based add-on that tried to open windows on start
2. run it via jpm -b -v run

Error: https://gist.github.com/canuckistani/c813b2a7169ef8e06762

Delaying by ~200msec on a Macbook Air seems to fix this. Test code is here:

https://github.com/canuckistani/dump-bugs

https://groups.google.com/d/msg/mozilla-labs-jetpack/YkdrGm0iiBY/TMz3UKAFWacJ
I added manually @jetpack and it worked indeed.

JPM should pre-configure firefox profile such that, [email protected] is set to "verbose" when --verbose param is passed. We may add other logLevels in a future.

JPM should allow us to run / test add-on with a local SDK modules rather than one shipped with firefox itself. This is not an end user feature, it's an SDK hacker feature
to test changes made to an SDK itself.

jpm --sdk-path /path/to/sdk should generate FF profile with extensions.modules.ADDON-ID.path preference set to /path/to/sdk/lib/, that way bootstrap.js will configure loader such that add-on will load sdk modules from local clone rather than from resource://gre/modules/commonjs/.

JPM should also recognize JETPACK_PATH environment variable (although precedence should be given to a CLI arg) to reduce overhead of passing arguments each time.

At the moment JPM completely ignores prefs. This will break most add-on's so it's no go.
Although fixing Bug 903039 is another way to get there, since it would replace need for options.xul or default/prefs.js.

JPM should pre-configure firefox profile such that [email protected] is set to true if --profile-memory flag is used when executing jpm.

JPM should pre-configure firefox profile such that [email protected] is set to a value followed --filter flag when when executing jpm.

I've observed that behavior with Firefox Aurora open on Ubuntu.

jpm run opens the “Choose User Profile” window instead of creating a new profile automatically. And after selecting a profile, jpm’s process gets closed.

Mentioned in google groups, investigate

When -v is not used the list of failed tests is not displayed.

At the moment nothing is printed into stdout until process exits.

Given that legacy add-ons used to have lib/main.js instead of ./index.js as entry point
JPM should validate that expected entry point module exists. If for example no main is in
package.json and ./index.js isn't present either JPM should dump warning and maybe
even suggest update to a package.json to assist migrating an add-on.

JPM should pre-configure firefox profile such that [email protected] is set to "tbpl" if jpm is executed with --parseable flag.

In a future we may add other output styles.

JPM should pre-configure profile such that [email protected] is set to either "run" or "test" depending whether jpm run or jpm test was executed.

Hi, I am willing to do early testing and found I could build
https://github.com/canuckistani/fennec-plus
in cygwin (for real command history as opposed to cmd.exe) with following versions:

me@myPC:~/tmp/mozilla/fennec-plus$ npm -v
1.2.18
me@myPC:~/tmp/mozilla/fennec-plus$ node -v
v0.10.4
me@myPC:~/tmp/mozilla/fennec-plus$ jpm -V
0.0.4
me@myPC:~/tmp/mozilla/fennec-plus$

First

I can install the add-on in Firefox Nightly of today in Windows XP SP3 (even though its functionality is limited to fennec) but the add-on is listed as

undefined 0.1
by undefined

Second

I'd love to build it for fennec.
Is the equivalent of the cfx --force-mobile available in jpm yet?

Just typing jpm after install does nothing. Maybe it should display the help or something?

Currently errors thrown in Firefox/Addons go to stdout in the process spawned by jpm, so we'll have to do some clever parsing to determine if it's an error, as this should be logged regardless of verbosity level set.

Create simple addon and run tests:
jpm init && jpm test -b /Applications/Firefox\ Nightly.app

There should be 3 tests run and I only get 1 of 1 tests passed., and it also looks like none of the tests actually get executed

// @erikvold

Once https://bugzilla.mozilla.org/show_bug.cgi?id=1009334 lands, the bootstrap file from the addon-sdk repo will be shipped with Fx, and at that point we should use it instead of a separate one shipped with this repo.

{
  "name": "toolbar-api",
  "title": "toolbar-api",
  "id": "toolbar-api",
  "main": "./lib/main.js",
  "description": "a toolbar api example",
  "author": "",
  "license": "MPL 2.0",
  "version": "0.1",
}

Generates:

<?xml version="1.0" encoding="utf-8"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#">
    <Description about="urn:mozilla:install-manifest">
          <em:id>unknown@jetpack</em:id>
          <em:version>undefined</em:version>
          <em:type>2</em:type>
          <em:bootstrap>true</em:bootstrap>
          <em:unpack>false</em:unpack>
          <em:name>Untitled</em:name>
          <em:homepageURL/>
          <em:description/>
          <em:creator/>
          <em:iconURL>icon.png</em:iconURL>
          <em:icon64URL>icon64.png</em:icon64URL>


    </Description>

</RDF>

Expected:

1. To see an error because of invalid id.

Actual:

1. Got install.rdf with unknown@jetpack id.
2. Got install.rdf that has no targetApplication.
3. Got install.rdf that has name set to Untitled.
4. Got install.rdf that has version set to undefined.

It's very easy to xpi up a xpi:

jpm xpi // creates a xpi
jpm run // creates a new xpi, containing previous xpi

This gets heavy and slow fast, so we should ignore compressed files when creating a xpi.

When transitioning from cfx to jpm, there are some differences that are no longer supported or done differently. When doing anything in jpm, before any actions are executed, a "health check" will be performed, ensuring that the addon will work with jpm, based off of these changes.

• ID Check: cfx creates invalid IDs for AOM and makes it valid during a build -- we no longer support this magic and valid IDs are required. If the ID provided is not valid (should pass jsantell/jetpack-id), display a message that this needs changed.
• Entry Point: cfx does not require a main entry point in the package.json and by default it is lib/main -- for consistency with node, toolkit/loader defaults to index.js if not specified.
  • If a main entry is not specified, and index.js does not exist, alert the user.
  • If a main entry is specified, but the file does not exist, alert the user.