異なる/フィルターされたクラスで複数のjarを生成するためのMavenベストプラクティス？
さまざまなプロジェクトで使用するJavaユーティリティライブラリ（Apache Commonsと同様））を開発しました。ファットクライアントに加えて、モバイルクライアント（PDA、J9 Foundationプロファイル）にも使用しています。単一のプロジェクトとして開始されたライブラリーが複数のパッケージにまたがっていたため、結果として、すべてのプロジェクトで実際に必要なわけではない多くの機能が使用されてしまいます。
このライブラリは一部のモバイル/ PDAプロジェクト内でも使用されるため、使用したクラスだけを収集して実際の特殊なjarを生成する方法が必要です。
現在、このライブラリを使用しているプロジェクトには、専用のjarファイル（例：my-util-1.0-pda.jar、my-util-1.0-rcp.jar）を（ユーティリティプロジェクトから）生成するAnt jarタスクがあります。 include/exclude jarタスク機能の使用。これは、モバイルプロジェクトの場合、生成されたjarファイルのサイズの制約により、主に必要です。
今すぐMavenに移行していますが、似たようなものに到達するためのベストプラクティスはあるのでしょうか。次のシナリオを検討します。
[1]-メインjarアーティファクトに加えて（my-lib-1.0.jar）も内部で生成my-lib別のプロジェクト/ Maven JarプラグインまたはMavenアセンブリプラグインフィルタリング/インクルードを使用した分類子（例：my-lib-1.0-pda.jar）を使用した特殊なアーティファクト。ライブラリの利用者の要求（フィルター）でライブラリを汚染するため、このアプローチにはあまり慣れていません。
[2]-「my-lib」を「ラップ」し、フィルタリングされたjarアーティファクトを生成するすべての専用クライアント/プロジェクト用に追加のMavenプロジェクトを作成します（例：my-lib -wrapper-pda-1. ...など）。その結果、これらのラッパープロジェクトにはフィルタリングが含まれ（フィルタリングされたアーティファクトを生成するため）、「my-lib」プロジェクトのみに依存し、クライアントプロジェクトはmy-lib-wrapper-xxx-1.my-lib-1.の代わりに。 「my-lib」プロジェクトをそのままにして（追加の分類子やアーティファクトなし）、このアプローチは問題があるように見えるかもしれません。すべてのクライアントプロジェクトに必要なものを収集するためだけに1つのライブラリがあるので、基本的にプロジェクトの数が2倍になります「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の方法」で解決するためのベストプラクティスは何ですか？
Mavenの一般的なルールは、モジュール化のために「POMごとに1つの主要なアーティファクト」であり、この規則を（一般的に）破ってはならない理由は 1つのプロジェクトから2つのJARを作成する方法（ ...そしてなぜしてはいけないのか） ブログ投稿。ただし、正当化される例外があります（たとえば、EJB JARを生成するEJBプロジェクトと、インターフェースのみのクライアントEJB JAR）。そうは言っても：
上記の ブログ投稿 （また、 規約を使用できない場合のMavenの使用 も確認してください）=オプション1個別のプロファイルまたはJARプラグインを使用します。このソリューションを実装する場合、これは例外であり、依存関係の管理が難しくなる可能性があることに注意してください（前述のように、「クライアントフィルタリングロジック」でプロジェクトを汚染します）。念のため、ここではJARプラグインの実行をいくつか使用します。
オプション2はオプション1IMO（それは別のものです）：基本的に、他のN個のラッピング/フィルタリングプロジェクトがあることは、1つのプロジェクトにN個のフィルタリングルールがあることと非常に似ています。フィルタリングが理にかなっている場合は、オプション1を選択します。
オプション3はまったく好きではありません。不要なものを「取り除く」ことは、ライブラリのクライアントの責任ではないはずです。 。第1に、クライアントプロジェクトは必ずしも必要な知識（何をトリミングするか）を持っているわけではなく、第2に、他のプラグインで大きな混乱を引き起こす可能性があります。
[〜＃〜] but [〜＃〜]ファットクライアントがでない場合my-lib全体を使用すると（サーバー側のコードではEJB JAR全体が必要になるため）、フィルタリングは適切ではありませんあなたの状況を処理する方法」。正しい方法はオプション4です：プロジェクトで一般的なすべてのものを配置します（my-lib-core-1.0を生成する.jar）および特定のプロジェクトの特定の部分（my-lib-pda-1.0.jarなどが生成されます）など）。その後、クライアントはコアアーティファクトと特殊なアーティファクトに依存します。