マルチプロジェクトのビルド問題
ソフトウェアの開発に伴い、ソフトウェア自体がますます複雑になります。大規模なプロジェクトを複数のモジュールに分割して開発することがよくあります。Mavenを使用してビルドすると、分割されたモジュールは実際には複数の異なるMavenになりますプロジェクト。
このような状況下では、マルチモジュールプロジェクトの構築は2つの問題に直面します。
1.分割されたモジュールが多い場合、プロジェクトごとにビルドコマンドを個別に実行する必要があります。これにより、ビルドの効率が低下することは間違いありません。
2.マルチプロジェクト構築の構成には多くの一般的な構成があります。たとえば、プロジェクトのgroupIdとバージョンは、依存関係があるため、一貫している必要があります。多くのプロジェクトでは、一般的な依存関係が導入されますが、メンテナンスには役立ちません。
上記の2つの問題を解決するために、Mavenは集約と継承の2つの機能を提供します。
総計
集約の役割は、コマンドを実行して2つ以上のプロジェクトを構築できることです。コマンドによって実行されるプロジェクトも、独立した追加プロジェクトである必要があります。集約プロジェクトのPOM構成は次のとおりです。
<artifactId>pro-test-aggregator</artifactId>
<groupId>com.cic</groupId>
<version>1.0-SNAPSHOT</version>
<modelVersion>4.0.0</modelVersion>
<packaging>pom</packaging>
<modules>
<module>pro-test1</module>
<module>pro-test2</module>
</modules>
このようにして、pro-test-aggregatorプロジェクトの下でMavenビルドコマンドを実行すると、Mavenはこの構成を解析し、Reactorビルド順序を計算します。つまり、宣言順にビルドされたすべてのモジュールで構成されるビルド構造が検出されます。依存するモジュールがある場合は、最初に依存するモジュールをビルドします。プロジェクト間の循環依存を回避するように注意してください。そうしないと、エラーがビルドされます。
最後に、指向性非循環グラフリアクターは解析のために解析されます。もちろん、ビルドされるプロジェクトとビルドされないプロジェクトをコマンドラインで制御することもできます。この機能は、テーラードリアクターと呼ばれます。
相続
クラス間の継承と同様に、Mavenの反復構成の機能は継承とも呼ばれ、継承により、1つの宣言と複数の参照を実装できます。既存の親プロジェクトは次のように定義されています。
<groupId>com.cic</groupId>
<artifactId>parent</artifactId>
<packaging>pom</packaging>
<name>parent</name>
<version>1.0-SNAPSHOT</version>
親プロジェクトの寿命は他のプロジェクトとそれほど変わらないことがわかりますが、パッケージ化の方法は集約プロジェクトに似ており、これも「pom」です。
サブプロジェクトは、継承を実現するために次のように構成されています
<parent>
<groupId>com.cic</groupId>
<artifactId>parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>pro-test1</artifactId>
<name>pro-test1</name>
親ノードは親プロジェクト情報を構成します。<relativePath>子ノードがあり、親プロジェクトのpom.xmlを見つけることができます。このアイテムが構成されていない場合、デフォルトは<relativePath> ../ pom.xml </ relativePath>です。ファイル、それはローカル倉庫に行き、見つけて見つけます。子プロジェクトはgroupIdとバージョンを宣言せず、デフォルトで親プロジェクトから継承できます。子プロジェクトの要素が親プロジェクトと異なる場合は、宣言を完全に表示できます。
groupId、バージョン、プロパティ(カスタムMaven属性)、依存関係、dependencyManagement、リポジトリ、その他のプロジェクト情報など、継承可能なPOM要素は多数あります。すべてのプロジェクトPom構成がMavenによって提供されるスーパーPOMを継承していることは注目に値します。これは、非常に少ない構成でMavenプロジェクトを構築できることも説明しています。
依存関係管理
依存関係ノードを使用して依存プロジェクトを均一に定義できますが、ここで問題があります。依存関係を通じて依存関係が親プロジェクトで定義されている場合、サブプロジェクトは親プロジェクトのすべての依存関係を継承します。つまり、サブプロジェクトが依存していないプロジェクトが導入される可能性があります。代わりに、混乱があります。この問題を解決するには、<dependencyManagement>ノードを使用して、親プロジェクトの依存関係を定義できます。子プロジェクトは、親プロジェクトを継承した後、依存関係を直接導入しませんが、それを示すために再度表示する必要があります。継承への依存。具体的な構成は次のとおりです。
親プロジェクト
<dependencyManagement>
<dependencies>
<!-- Common libs -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.bom.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>${spring.bom.version}</version>
<type>pom</type>
<scope>import</scope>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</dependencyManagement>
サブプロジェクトの構成は次のとおりです
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
</dependency>
</dependencies>
この構成方法を使用すると、構成はそれほど削減されませんが、依存バージョンは親プロジェクトで一元管理でき、各依存パッケージのバージョンは<properties>ノードの下で一律に定義できます。
注意深い読者は、親プロジェクトに<spring-framework-bom>プロジェクトを導入したときに、<scope>ノード属性が「import」値で構成されていることを発見しました。これは、ターゲット依存関係の<dependencyManagement>ノードのコンテンツがインポートされ、現在のプロジェクトの下で、この依存プロジェクトのPomファイルを表示できます。これは、Springプロジェクトに関連する一連のモジュールを定義しているため、現在のプロジェクトの依存関係構成を簡素化します。
同様に、依存関係に対応して、プラグインの管理にも同様の構成ノード<pluginManagement>があり、その効果は依存関係管理と同様なので、ここでは繰り返さない。
まとめ
この記事では、マルチプロジェクトの問題に対処するためのMavenの2つの機能、提案された集約と継承について紹介します。これら2つの学習ポイントがあれば、複数のモジュールを分割して構成するときに、これら2つの構成ポイントをうまく活用できると思います。同時に、Mavenのコアデザインコンセプト「コンベンションはコンフィギュレーションよりも優れている」の実現メカニズムも理解できます。