1

私の会社は、そのソフトウェアのJavaAPIを使用するプロジェクト管理ソフトウェアのコンパニオン製品を作成しています。彼らは、製品の新しいリリースとともに新しいAPIバージョンをリリースし、バグ修正などのポイントリリースもリリースします。さまざまなバージョンのソフトウェア（ひいてはAPI）を使用するクライアントをサポートする必要があります。不要なコードの重複なしにこれを行うために、各APIバージョンに必要な依存関係を含むプロファイルを製品に定義しました。

「api70」プロファイルをアクティブにしてこの手法を使用して構築された戦争プロジェクトと、戦争の依存関係を引き出すために、pomのタイプでその戦争プロジェクトに依存する別のプロジェクトがあります。問題は、この2番目のプロジェクトをビルドするときに、依存するプロジェクトをビルドするときにmavenコマンドラインで-Papi70を定義しているにもかかわらず、プロファイル固有の依存関係が含まれていないことです。

これを機能させる方法はありますか？

戦争プロジェクトでは：

<!-- API 7.0 profile. -->
<profile>
  <id>api70</id>

  <dependencies>
    <dependency>
      <groupId>com.bigcompany</groupId>
      <artifactId>integrationlibrary</artifactId>
      <version>7.0-a</version>
    </dependency>
  </dependencies>

  <properties>
    <apiversion>api70</apiversion>
  </properties>

</profile>

依存するプロジェクトでは：

<!-- Depend on war as type=pom for dependency mediation. -->
<dependency>
  <groupId>com.mycompany</groupId>
  <artifactId>warproject</artifactId>
  <version>${warVersion}</version>
  <type>pom</type>
</dependency>

依存プロジェクトの構築に使用されるコマンドライン：

mvn -P api70 clean package

結果のビルドには、integrationlibraryまたはその推移的な依存関係は含まれません。

4

2 に答える 2

0

あなたの問題はプロファイルにはまったく当てはまらないと思います。それは、戦争パッケージングで推移的な依存関係がどのように機能するかについてです。設計上、これらは機能しません:) Warアーカイブは、WEB-INF / libフォルダーに依存関係を含んでいるか、earにパッケージ化されている場合は、earlibsとライブラリを共有できます。このウィキの記事で読むことができる問題の詳細。スキニーウォーズについてですが、トピックはあなたの問題にも関係しています。

あなたにとって興味深いのは、このJIRAの問題でもあります。

迅速ですがエレガントではない解決策は、パッケージを戦争からpomに変更することです（またはpomパッケージで重複したpomを作成します）。

于 2009-10-29T20:48:23.137 に答える
0

api70-deps pom プロジェクトを作成し、war と依存プロジェクトの両方にそれを取り込ませたり、プロファイルをアクティブにしたりしないのはなぜですか?

このアプローチは私にとって驚異的に機能します...私のポンポンはとてもきれいになります。

于 2009-12-16T11:59:03.667 に答える