現在Mavenに変換されているAntビルドがあります。ただし、Antビルドには2つのビルドターゲットがあります。1つはアプリ全体をビルドするもので、もう1つはそれらのファイルの一部(ほんの一部)からJARをビルドするものです。 Antでは、これを処理するために複数のビルドターゲットを設定するのは簡単ですが、Mavenでこれを処理する最良の方法を決定しようとしています。
ファイルのサブセットを2つ目のプロジェクトに分割すると、独自のPOMができます。その後、最初のプロジェクトはこれに依存する可能性があります。ただし、ファイルのサブセットは非常に小さい(10未満)ため、そのためのまったく新しいプロジェクトを作成するのはやり過ぎかもしれません。
これを処理する他の方法はありますか?
あなたの最初の考えは正しいものです。 2つの部分を2つのプロジェクトに分割します。
Mavenの哲学は、各プロジェクトで1つだけのアーティファクト(jar、warなど)を構築することです。
あなたはおそらく何かを一緒にハックして、2つのアトリファクトを構築する1つのmavenプロジェクトだけを作ることができますが、それはハックになります。
Mavenからantを呼び出すことができるので、これを本当に実行したい場合は、maven antプラグインを確認することをお勧めします。アーティファクトIDは「maven-antrun-plugin」です
これはプロファイルで実行できます...
本当に2つの個別のプロファイルを使用し、クラスとパッケージ名のパターンを含めたり除外したりするようにJARプラグインをカスタマイズしたい場合は、POMに次のようなものを置くことで簡単にこれを行うことができます。
<profiles>
<profile>
<id>everything</id>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<classifier>everything</classifier>
<includes>
<include>**/*</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>only-library</id>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<classifier>only-library</classifier>
<excludes>
<exclude>**/Main*</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
余談ですが、それが多くの構成のように思える場合、Groovy POMに対するpolyglot Mavenのサポートはほぼ準備ができています。行数が大幅に削減されます。
これをpom.xmlの最後に(プロジェクト要素とともに)配置し、2つのプロファイルを追加します。最初のプロファイル「すべて」は、実際に構成を示すためだけにあります。この「すべて」のプロファイルは、デフォルトのJARプラグインjarゴールの実行の動作を単純に複製するため、不要です。 2番目のプロファイル「only-library」は、テキスト「Main」で始まるパッケージ内のクラスを除外します。これらのプロファイルを呼び出すには:
mvn package -Peverything
mvn package -Ponly-library
私は 例によるMavenの第6章 に付属するサンプルアプリケーションに対してこれをテストし、これらのコマンドのいずれかを実行すると、分類子を持つ$ {basedir}/targetにJARファイルが生成されます。 JARプラグインのjar目標はデフォルトのmavenライフサイクルのパッケージフェーズにバインドされているため、これらの2つのプロファイルはこのプラグインの構成を変更します。
または、2つのJARプラグインを実行してこれを行うことができます...
プロファイルを使用せずに2つのJARを作成する必要がある場合。 JARプラグインのjarゴールをパッケージライフサイクルフェーズに複数回バインドし、構成された実行ごとに異なる構成を使用できます。 2つの個別の実行を構成する場合、各実行には実行固有の構成ブロックがあるため、一意の識別子を指定し、実行ごとにパターンを含めたり除外したりできます。
次に、両方のカスタムJARをライフサイクルフェーズの「パッケージ」に追加するために使用するビルド要素を示します。 「jar」をパッケージ化したプロジェクトでこれを行うと、jarゴールが3回実行されます。 1回はデフォルトのライフサイクルバインディングとして、2回は2つのカスタム分類JARです。
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>only-library</id>
<goals><goal>jar</goal></goals>
<phase>package</phase>
<configuration>
<classifier>only-library</classifier>
<excludes>
<exclude>**/Main*</exclude>
</excludes>
</configuration>
</execution>
<execution>
<id>everything</id>
<goals><goal>jar</goal></goals>
<phase>package</phase>
<configuration>
<classifier>everything</classifier>
<includes>
<include>**/*</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
各アーティファクトに異なるクラスのセットを含めることについて話していない場合は、Mavenアセンブリを使用することをお勧めします。アセンブリの詳細を知りたい場合は、Mavenのこの回答の最後に、完全なリファレンスの章がリストされています。率直に言って、私はこの特定の章が良い入門的なリファレンスであるとは思いません。実際、私はこの章がほとんど読めない(そして私たちはそれを修正するために取り組んでいる)との多数の報告をしました。アセンブリを使用する場合は、 Mavenアセンブリプラグインのドキュメント をお勧めします。左側のナビゲーションメニューに、サンプルのアセンブリ記述子のリストが表示されます。
免責事項:(お願い)これを行わないでください。 2つの異なるクラスセットを使用して2つの異なるJARを作成する場合、プロジェクトを2つの相互依存するモジュールに分割することを強くお勧めします。
プロファイルを使用してこれを行うことができますが、プロジェクトを2つ(実際には3つ)に分割する方が簡単です。長期的には、アプリケーションのスケーリングに伴って直面する課題があります。分類された各JARに含まれるクラスとパッケージのこの手動リストを把握する必要があります。
2つの個別のモジュールを参照する単純な親プロジェクトを持つことによるオーバーヘッドは最小限です。無料のMaven by Exampleブックをご覧になる場合は、単一モジュールプロジェクトとマルチモジュールプロジェクトの間の移行方法を示します。 第3-5章 単一モジュールプロジェクトに焦点を当て、 第6章 は、これらの単一モジュールコンポーネントをより大きなマルチモジュールプロジェクトに組み合わせる方法を示しています。
詳細:
質問には次のトピックが含まれます。ここでは、それぞれの詳細を提供するリンクをいくつか示します。
Maven JARプラグイン: http://maven.Apache.org/plugins/maven-jar-plugin/jar-mojo.html
マルチモジュールのMavenプロジェクト: 例によるMavenの第6章 および Mavenのセクション3.6.2:完全なリファレンス 。
Mavenライフサイクル(パッケージが「jar」の場合、jarはパッケージにバインドされます): 例「コア概念」によるMavenのセクション3.5.2 および Mavenの第4章:完全なリファレンス
Mavenアセンブリ:最初に Mavenアセンブリプラグインサイト 、次に Mavenの第8章:完全なリファレンス は、かなり重い(ほとんど非常に重い)詳細です。
次の2つの選択肢があります。
サブセットがリソースのコレクションのみである場合、別のモジュールにすることはしません。
プロジェクトが常に統一された方法でパッケージ化されているサブセットに依存している場合、サブセットは モジュール になるための良い候補です。
サブセットが複数の異なる「フレーバー」に再パッケージ化されている場合は、「フレーバー」ごとにアセンブリを定義し、アーチファクト名を「分類子」で修飾します maven座標 を参照してください。
最後に、プロファイルを使用して、生成されるアセンブリを決定できます。デフォルトのプロファイルでは、開発中に必要な初期のアーティファクト「フレーバー」のみを作成できます。
「完全な」プロファイルは、開発が完了すると、最終的な展開のためにアーティファクトのすべての「フレーバー」バリアントを生成する場合があります。