私は、さまざまなプロジェクトで使用する Java ユーティリティ ライブラリ (Apache Commons に類似) を開発しました。ファット クライアントに加えて、モバイル クライアント (J9 Foundation プロファイルの PDA) にも使用しています。1 つのプロジェクトとして始まったライブラリは、やがて複数のパッケージに広がりました。その結果、すべてのプロジェクトで実際に必要というわけではない多くの機能を持つことになります。
このライブラリは一部のモバイル/PDA プロジェクト内でも使用されるため、使用されるクラスだけを収集し、実際の特殊な jar を生成する方法が必要です。
現在、このライブラリを使用しているプロジェクトには、include/exclude jar タスク機能を使用して (ユーティリティ プロジェクトから) 特殊な jar ファイル (例: my-util-1.0-pda.jar、my-util-1.0-rcp.jar) を生成する Ant jar タスクがあります。これは主に、モバイル プロジェクトで生成された jar ファイルのサイズ制約のために必要です。
現在 Maven に移行していますが、同様の結果を得るためのベスト プラクティスがあるかどうか気になっています。次のシナリオを検討します。
[1]- メインの瓶アーティファクトに加えて（my-lib-1.0.jar）内部でも生成マイライブラリ分類器を使用して個別の/特殊な成果物を投影する（例：my-lib-1.0-pda.jar) を Maven Jar プラグインまたは Maven アセンブリ プラグインのフィルタリング/インクルードを使用して作成します。このアプローチは、ライブラリ コンシューマーの要求 (フィルター) によってライブラリが汚染されるため、あまり快適ではありません。
[2]- すべての特殊なクライアント/プロジェクト用に、"my-lib" を "ラップ" してフィルターされた jar 成果物を生成する追加の Maven プロジェクトを作成します (例:my-lib-ラッパー-pda-1.0...など）。その結果、これらのラッパープロジェクトにはフィルタリング（フィルタリングされた成果物を生成する）が含まれ、「my-lib」プロジェクトのみに依存し、クライアントプロジェクトは私のライブラリラッパーxxx-1.0の代わりにマイライブラリ1.0このアプローチは、"my-lib" プロジェクトがそのまま (追加の分類子や成果物なしで) 残るため、問題に見えるかもしれません。基本的に、クライアント プロジェクトごとに 1 つのライブラリがあり、"my-util" ライブラリから必要なクラスを収集するためだけにプロジェクト数が 2 倍になります ("my-pda-app" プロジェクトには "my-lib-wrapper-for-my-pda-app" プロジェクト/依存関係が必要です)。
[3]- ライブラリを使用するすべてのクライアント プロジェクト (例:私のPDAアプリ) 最終的な成果物/パッケージを生成するときに、不要なクラスを削除する特殊な Maven プラグインを追加します (例: maven-assembly-plugin、maven-jar-plugin、proguard-maven-plugin)。
この種の問題を「Maven 方式」で解決するためのベスト プラクティスは何ですか?
ベストアンサー1
Mavenの一般的なルールは、モジュール性のために「POMごとに1つの主要なアーティファクト」であり、この慣例を破るべきではない理由（一般的に）は、1 つのプロジェクトから 2 つの JAR を作成する方法 (...そしてなぜそうすべきではないのか)ブログ投稿。ただし、正当な例外もあります (たとえば、EJB JAR とインターフェイスのみを含むクライアント EJB JAR を生成する EJB プロジェクトなど)。そうは言っても、
言及されたブログ投稿（こちらもチェック規約が使えない場合のMavenの使用）では、どのように実装できるかを説明しますオプション1別々のプロファイルを使用するか、JARプラグインこのソリューションを実装することに決めた場合は、これは例外であり、依存関係の管理が複雑になる可能性があることに留意してください (そして、あなたが述べたように、プロジェクトが「クライアント フィルタリング ロジック」で汚染される可能性があります)。念のため、ここではいくつかの JAR プラグイン実行を使用します。
オプション2あまり変わらないオプション1私の意見では (分離しているという点を除いて)、基本的に、N 個の他のラッピング/フィルタリング プロジェクトを持つことは、1 つのプロジェクトに N 個のフィルタリング ルールを持つことと非常に似ています。フィルタリングが理にかなっている場合は、オプション 1 の方を好みます。
私は好きではありませんオプション3ライブラリのクライアントが不要なものを「削除」する責任はないと思うので、まったくそうではありません。第一に、クライアント プロジェクトには必ずしも必要な知識 (削除するもの) があるわけではなく、第二に、これにより他のプラグインに大きな混乱が生じる可能性があります。
しかしファットクライアントがない全体を使ってマイライブラリ（サーバー側のコードがEJB JAR全体を必要とするなど）フィルタリングは状況に対処するための正しい「Mavenの方法」ではありません。正しい方法はオプション4: プロジェクトに共通するものをすべて入れる（生産my-lib-core-1.0.jar）および特定のプロジェクトの特定の部分（生産されるmy-lib-pda-1.0.jarなど)。クライアントはコアアーティファクトと特殊なアーティファクトに依存することになります。