さまざまなプロジェクトで使用する Java ユーティリティ ライブラリ (Apache Commons と同様) を開発しました。ファット クライアントに加えて、モバイル クライアント (J9 Foundation プロファイルの PDA) にも使用します。単一のプロジェクトとして開始されたライブラリは、やがて複数のパッケージに広がりました。その結果、すべてのプロジェクトで実際には必要とされない多くの機能が必要になります。
このライブラリは一部のモバイル/PDA プロジェクト内でも使用されるため、使用されているクラスだけを収集して実際の特殊な jar を生成する方法が必要です。
現在、このライブラリを使用しているプロジェクトには、(ユーティリティ プロジェクトから) 特殊な jar ファイル (例: my-util-1.0-pda.jar、my-util-1.0-rcp.jar) を生成する Ant jar タスクがあります。 jar タスクの組み込み/除外機能を使用します。これは、モバイル プロジェクト用に生成された jar ファイルのサイズの制約により、主に必要になります。
今Mavenに移行していますが、似たようなものに到達するためのベストプラクティスがあるかどうか疑問に思っています. 次のシナリオを検討します。
[1] - メインの jar アーティファクト ( my-lib-1.0.jar ) に加えて、分類子 (例: my-lib-1.0-pda.jar ) を使用して Maven Jar プラグインを使用して、my-libプロジェクト内で個別の/特殊化されたアーティファクトを生成します。または Maven アセンブリ プラグインのフィルタリング/インクルード。このアプローチは、ライブラリの消費者の要求 (フィルター) でライブラリを汚染するため、あまり快適ではありません。
[2] - 「my-lib」を「ラップ」し、フィルタリングされた jar アーティファクト (例: my-lib-wrapper-pda-1.0 ...など)を生成する、すべての特殊なクライアント/プロジェクト用の追加の Maven プロジェクトを作成します。 . その結果、これらのラッパー プロジェクトには (フィルター処理されたアーティファクトを生成するための) フィルター処理が含まれ、"my-lib" プロジェクトのみに依存し、クライアント プロジェクトはmy-ではなくmy-lib-wrapper-xxx-1.0に依存します。 lib-1.0. このアプローチは問題があるように見えるかもしれません. 「my-util」ライブラリのクラス (「my-pda-app」プロジェクトには「my-lib-wrapper-for-my-pda-app」プロジェクト/依存関係が必要です)。
[3] - ライブラリを使用するすべてのクライアント プロジェクト (例: my-pda-app ) で、特殊な Maven プラグインをいくつか追加して、(最終的なアーティファクト/パッケージを生成するときに) 不要なクラス (例: maven-assembly -plugin、maven-jar-plugin、proguard-maven-plugin)。
「Maven の方法」でこの種の問題を解決するためのベスト プラクティスは何ですか?