BT

InfoQ ホームページ ニュース OSGiがスナップショット提案を破棄

OSGiがスナップショット提案を破棄

ブックマーク

原文(投稿日:2012/04/04)へのリンク

最近リリースされたOSGi Release 5 早期アクセスドキュメントによると、次回の仕様で最も期待されていたフィーチャの1つ、OSGi向けSNAPSHOTスタイルバージョンが 仕様から落とされた 。既存のツール群への懸念のためである。

しかし、既存のツール群、管理とプロビジョニングシステムとのやりとりで、大きな懸念がある。これらのシステムは、プレリリースバージョン文字列を持つバンドルを理解できない。これらがプレリリースバージョンシンタックスを適切にサポートできるようにするには、かなりの変更が必要である。

問題の原因は、空の修飾子(qualifier)を扱う方法がMaven(そしてMaven互換のリゾルバー/ビルド システム例えば、 Ivy やGradle)とOSGiとでは逆なことから来ている。Mavenでは、 1.2.3.2012 <= 1.2.3だがOSGiでは1.2.3.2012 >= 1.2.3である。

このことが問題となるのは、非OSGi 環境(例えばMavenを使っている)で動き、しかもOSGi コンテナ内で走ることを意図しているコンポーネントと協調できるコンポーネントをビルドする時である。Maven流では、(いくつもの) 2.1-SNAPSHOTビルドで開発して、最後にバージョンナンバーを 2.1に置き換える。しばしばリポジトリマネージャ( 例えばArtifactory や Nexus)がスナップショットをトレーサビリティのために発行した日付の付いたファイルに書き換える。

Eclipse PDEビルド、そして Maven Tychoは、明示的に各ビルドされたコンポーネントに名前をつけるが、変更した日付/タイムスタンプをつけるのが一般的である。各ビルドされたコンポーネントに新しい名前がつくので、新バージョンがこれまでのものを上書きして、バージョン番号が増加しながらOSGi ランタイムにインストールされることになるだろう。

不幸にしてこのことは、「最後の」リリースされたコンポーネントのバージョンもビルド修飾子 を含むことになる、ということであるが、これはある場合には、成果物自身の名前よりも長い場合がある(例えばorg.junit_4.8.2.v4_8_2_v20110321-1705)。それらはまた、修飾子のフォーマットにおいても一貫していない(例えば、org.eclipse.jdt.ui_3.7.1.r371_v20110824-0800.jar )。

SpringSourceのようなプロデューサーは、 1.2.3.M1, 1.2.3.M2, 1.2.3.RELEASE 形式のバージョンを生成する。これだと OSGi と Mavenの両方に使える。

OSGi用に-SNAPSHOT スタイルのバージョンをサポートすることがこの問題を解決する。 Bundle-Versionシンタックスは、1.2.3-4561.2.3より小さくソートするようにアップグレードされる、ことが提案された(そしてEquinoxでは実装され) さえした)。こうすれば、bundle開発者は、-SNAPSHOT スタイルの派生版( Tycho や PDEのようなツールでは、 .qualifierの代わりに「マジック置換値」として -SNAPSHOT を使っている)を開発用に使え、その一連のビルド用のみに 1.2.3をリリースできる。その後は、1.2.4-SNAPSHOTに飛ぶわけである。

不幸にして、持ち上がった懸念は、経験によるものではなく推測によるものだった。

更に我々はまた、プレリリースバージョンの精神的な複雑さについて心配しだした。 CPEG内と仲間内の多くの議論で、バージョンの順序付けとあるバージョンは、ある範囲に含まれる、と人々は混乱するだろう、と言われた。もし我々のような「専門家」が我々の頭の中でスッキリできなければ、他の人達は大変だろうと考えた。

複雑はどのようにビルド範囲が関係しているかによっていた。[1.0,2.0) のような既存のユースケースが考慮された。この場合、1.0はスナップショット1.0-*を許し、もう一方の端である 2.0は許されない。結局、このルールは詰まるところ、もし境界値が入るなら、スナップショットを含み、境界値が範囲外ならスナップショットを含めない、ということである。これは覚えるのに難しくはない。

リスクは、この決定が実際に OSGi生成コンテンツの仕様を止めさせたことである。ほぼ一年間、Eclipseビルトの成果物をMaven名前空間でどのように表現するかの議論があった。コンポーネントをorg.eclipse.*スタイルグループにマップし、完全な成果物名を使ってやろうとした。しかし、この提案は単に 全ての修飾子を落とし て、少なくともMavenフロントエンドからは、人間にとって使うのがより簡単になる。

このことは、全てに修飾子使うユースケースで問題を強調している。開発者はバージョン番号を最新にするのを忘れて、ビルドを配布する時に自動生成された数値を使うだけである。その結果、 Eclipseリポジトリには同じメジャー/マイナー/パッチ番号を持つ複数の成果物があり、しかし違うビルド修飾子が付いている。ローカルの Eclipse 3.7インスタンスから 3.7.2にアップグレードされたものに、同じメジャー/マイナー/パッチバージョンの付いたプラグインのサブセットが以下のように存在する。

  • org.eclipse.cdt.codan.checkers.ui_1.0.0.201109151620.jar
  • org.eclipse.cdt.codan.checkers.ui_1.0.0.201202111925.jar
  • org.eclipse.core.filebuffers_3.5.200.v20110505-0800.jar
  • org.eclipse.core.filebuffers_3.5.200.v20110928-1504.jar
  • org.eclipse.core.variables_3.2.500.v20110511.jar
  • org.eclipse.core.variables_3.2.500.v20110928-1503.jar
  • org.eclipse.emf.ecore_2.7.0.v20110912-0920.jar
  • org.eclipse.emf.ecore_2.7.0.v20120127-1122.jar
  • org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110506.jar
  • org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110815-1438.jar
  • org.eclipse.equinox.p2.updatesite_1.0.300.v20110510.jar
  • org.eclipse.equinox.p2.updatesite_1.0.300.v20110815-1419.jar
  • org.eclipse.jdt.compiler.tool_1.0.100.v_B76_R37x.jar
  • org.eclipse.jdt.compiler.tool_1.0.100.v_B79_R37x.jar
  • org.eclipse.jface_3.7.0.I20110522-1430.jar
  • org.eclipse.jface_3.7.0.v20110928-1505.jar
  • org.eclipse.ltk.core.refactoring_3.5.201.r371_v20110824-0800.jar
  • org.eclipse.ltk.core.refactoring_3.5.201.r372_v20111101-0700.jar
  • org.eclipse.pde.runtime_3.4.201.v20110819-0851.jar
  • org.eclipse.pde.runtime_3.4.201.v20110928-1516.jar
  • org.eclipse.ui_3.7.0.I20110602-0100.jar
  • org.eclipse.ui_3.7.0.v20110928-1505.jar

問題は、これらの番号が一般に、ファイルシステムを見たり、番号を覚えようとする人には意味の無いことである。もし P2 や OBRのようなリポジトリツールを使って自分の成果物を実現するのであれば、どうでもいいことであるが、世界のビルドツールの多くは、明示的なバージョン番号と名前によって、依存性の Require-Bundleタイプを基にして、いまだに作られている。それはまた、多くの OSGiランタイムの管理を複雑にしている。インストールされているbundleの簡単な比較がもっと難しくなっている。

-SNAPSHOT/release/-SNAPSHOT モデルがこの問題を解決している。開発中には、バージョン番号が明示的に増加している(このことは、バージョン番号が最後に決まった後に、更にテストする段階を持つ可能性を完全に消し去ってはいない。しかし一般的には、その段階で問題が見つかると、とにかくパッチレベルに飛ぶことになる)。このプロセスはApache Felix プロジェクトで上手く、使われた。短い番号を使ってリリースのリスト を持ち、既存のビルドに再利用するのが簡単である。ほぼ間違いなく、 Equinoxより 頭に何もついていないOSGiビルドには、Apache Felixのようにビルドするのは、易しい。このこととMavenセントラルでは既に成果物が入手できることの両方が理由である。

InfoQの意見では、これは逃された機会である。提案された実装をやり遂げずに、取るに足らない懸念を基に、OSGi コアプラットフォームの専門グループは、ツール問題を人の問題にしてしまった。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。