などといいつつ、jpm の動作をいろいろ見ている。

cfx と同様、[cci]jpm xpi[/cci] とすることで xpi を生成することができる。ただし、[cci]–pkgdir[/cci] オプションや [cci]–update-link[/cci] オプションがどういう訳か削除されている。前者は、xpi をアーカイブする際のベースディレクトリを指定する。これがないということになっても、単に [cci]cd && jpm xpi[/cci] などとすればよいのでそれほど問題ではない。しかし後者が問題だ。

[cci]cfx xpi[/cci] においては以下のオプションが有効で:

• –update-link: 拡張を自動更新する際の最新の xpi ファイルの場所を指定する。このオプションを指定すると、cfx は update.rdf を生成する
• –update-url: 拡張を自動更新する際の更新情報を示す RDF ファイルの場所を指定する。この情報は xpi 内の install.rdf に埋め込まれる

この違いはとてもわかりにくい。前者は [cci]–location-of-latest-xpi[/cci]、後者は [cci]–location-of-update-manifest-rdf[/cci] などと脳内で変換する必要がある。

で。jpm では前述の通り [cci]–update-link[/cci] オプションが削除されている。従って、jpm は update.rdf を一切生成しない。そのため jpm ベースの開発サイクルでは update.rdf を自前で生成しなければならなくなっている。なぜこのような仕様変更が行われたのかはよく分からないが、自前で update.rdf を制御する場面というのは、つまり拡張を AMO 以外の場所で配布する状況ということだ。AMO に載せるのなら気にする必要はない。つまり update.rdf の生成機能が取り除かれているのは野良拡張の配布をやめろという暗黙的な圧力なのかもしれない。

この手の悪意に満ちた嫌がらせはこれだけではない。拡張に自前で署名を施すためのツールとして McCoy というものがあるのだが、これもあからさまに使いにくい。そして、「使いにくいけど将来的には直すので期待してね！」なんつったりしちゃったりしてるのだが、もちろん今現在になっても使いやすくなってはいない。

一方で Mozilla は

インストールを Mozilla の配布チャンネルに限定することは余計な制約であると私たちは考えます

とかなんとか言っている。なーんか、言ってることとやってることが全然違いますね。こんなことばかりやってると、加速度的に信用を失うと思うんですけど。

それはさておき、update.rdf のテンプレートから任意の箇所を package.json の値で置換するような適当な javascript のスクリプトを書いた。javascript で書いたのは、jpm 自体が node.js で動かすスクリプトなのでそれに合わせて。

テンプレートとしてこういうものを用意して







package.json とテンプレートを両方読んで、プレースホルダ（{{〜}} の部分）を package.json の該当する値で埋める。package.json に値が存在しなければ、プレースホルダを含む要素自体を空に置き換えるようにした。

とりあえず webliopane fx40fixed を jpm でビルドするようにしてみた。