1

バンドルA、B、Cがあります。Aには、バンドルBとCのそれぞれのパッケージbとcのコードに依存するパッケージ「a」が含まれています。

bundle A {
  package a

  export-package:a
}

bundle B {
  package b.a
  package b.b
  package b.c
  package b.d
  package b.e

  import-package: a
  export-package:b.a;uses:=a,
    b.b;uses:=b.a,
    b.c;uses:=b.b,
    b.d;uses:=b.c,
    b.e;uses:=b.d
}

bundle C {
  package c

  import-package: b.e,
    a
}

これらのバンドルをすべて一緒に更新すると、多くの場合、使用制約違反(Felixレポートスタイル)が発生します。

Chain 1:
  C [47.1]
    import: (&(osgi.wiring.package=a)(version>=1.1.0))
     |
    export: osgi.wiring.package=a
  A [9.1]

Chain 2:
  C [47.1]
    import: (&(osgi.wiring.package=b.e)(version>=1.0.0))
     |
    export: osgi.wiring.package=b.e; uses:=a
  B [33.0]
    import: (&(osgi.wiring.package=a)(version>=1.0.0))
     |
    export: osgi.wiring.package=a
  C [9.0]

私は当初、beが'a'のuses句を生成することに驚いていました。これは、これらのバンドルがプロビジョニングされるマニフェストまたはOBRrepository.xmlで宣言されていません。ただし、の型はAPIを介しての型を公開しているので、これが由来だと思います。

これらを解決する唯一の方法は、中間パッケージのエクスポートとインポートのバージョン番号を増やすことです。たとえば、この例ではそうです。ただし、最終的に「a」を推移的に使用するパッケージはたくさんあります。

つまり、「a」を更新するたびに、のすべての推移的な依存関係を新しいバージョンで更新する必要があります。これらのパッケージのバージョン番号を増やすために行うのは正しいことですか?他の唯一の方法は、コードの相互依存性が低くなるようにリファクタリングすることですか?

4

1 に答える 1

3

The uses constraints are not handled transitively by the resolver.

If bundle C imports b.e and b.e used b.d, then bundle C also needs to import b.d. That is, the public signature of b.e includes a reference to something in b.d. This is why we say b.e uses b.d. Therefore, any bundle which imports b.e must also import b.d. Otherwise the bundle cannot properly use b.e since some type referenced in b.e is not visible to the bundle.

For the export of b.e, it should state it uses b.d, b.c, b.b, b.a and a since using b.d means you also use b.c and so on...

Did you hand generate your uses clauses? Or was this example derived from something bnd generated?

于 2012-07-24T20:14:40.993 に答える