12

この投稿の長さについてお詫び申し上げますが、写真を提示せずに簡潔にするのに苦労しました。私は最近、Maven3.0マルチモジュールプロジェクトのビルドマスターの仕事を引き継ぎました。問題は、プロジェクト/モジュールの構造が災害であるということです。現在ソース管理（RTCを使用）に保存されている方法からモジュールのpom構造まで、毎回完全なビルドサイクルを完了させようとして、髪の毛を引き裂いています。

プロジェクト階層が進むにつれて、すべてのモジュールは「フラット」に保存されます。つまり、すべてが同じレベルにあります。私は親pomを持っており、すべてのモジュールは親に依存しています。ただし、親は他のすべてのモジュールと同じレベルにあります。

元：

c:\dev\MyEarProject
 + parent-pom
   - pom.xml
 + module1
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module2
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module3
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...

親pomは、プロジェクトのビルドに必要なすべてのモジュールと、さまざまなサブモジュール全体で使用されるアーティファクトのバージョン番号の一連のプロパティを定義します。

<modules>
  <module>../module1</module>
  <module>../module2</module>
  <module>../module3</module>
</modules>

<properties>
    <org.springframework.version>3.0.5.RELEASE</org.springframework.version>
    <slf4j.version>1.6.4</slf4j.version>
    <repositoryAddress>${snapshots.repo.url}</repositoryAddress>
    <my.hibernate-module.dao.impl>1.2.3</my.hibernate-module.dao.impl>
    <my.hibernate-module.dao.api>1.2.3</my.hibernate-module.dao.api>
</properties>

次に、各モジュールのpomは、pomのアーティファクト番号を介して親pomに依存します。

<parent>
    <groupId>com.cws.cs.lendingsimulationservice</groupId>
    <artifactId>parent-pom</artifactId>
    <version>1.0.6</version>
</parent>

さらに混乱させるために、実際のアーティファクト名は（モジュールに応じて）モジュールパスと一致する場合と一致しない場合があります。たとえば、module1はパスに配置されc:\dev\MyEarProject\module1ていても、アーティファクト名はhibernate-moduleです。ただし、RTCでの保存方法により、module1チェックアウト時にディレクトリが呼び出されます。

もちろん、すべてを構築する最も簡単な方法は、にアクセスしc:\dev\MyEarProject\parent-pom\て実行することmvn clean deployです。SNAPSHOTリポジトリでは同じアーティファクトバージョンの複数の展開が可能であるため、これはSNAPSHOTモードで正常に機能します。しかし、リリースモードでは、これは失敗します。

この構造は私にとって2つの問題を引き起こしています。

  1. 親のプロパティにバージョンを変更する必要があるたびに、親-pomのバージョン番号、すべての子モジュールの親pomのバージョン、およびすべての子モジュールのバージョン自体を更新する必要があります（親が変更されたため）。
  2. リリースサイクルをデプロイする必要があるときはいつでも、モジュールの1つが最後のサイクル以降変更されておらず、その結果、同じリポジトリに再デプロイできない場合、mvnはエラーをスローします（リポジトリは既存のアーティファクトの上書きを許可しません）

したがって、これらの問題を回避するために、このプロジェクトを再構築するための最良の方法を探しています。親pomの場合、代わりに相対パスを使用して親を指すことができます。ただし、モジュールの「フラットな」構造を考えると、これは推奨されるアプローチですか（つまり、親pomの相対パスは../parent-pom/pom.xmlになります-私には少し奇妙に思えます）？さらに、親のバージョン管理がモジュールから独立していることを考えると、相対パスを使用するだけでなく、追加の混乱への扉が開かれます（つまり、親pomのどのバージョンがどのバージョンに関連付けられているかを知る方法はありませんサブモジュールの）。

次に、発生しているデプロイエラーに遭遇することなく、耳全体を構築するにはどうすればよいですか？アーティファクトはすでにリポジトリに存在するため、再構築して再デプロイする必要はありません。--projectsを使ってみましたが、モジュールの数が多いため、管理が非常に難しくなります。

4

3 に答える 3

12

私が本当にお勧めする最初のことは、プロジェクト フォルダーを再構築することです。これは、プロジェクト フォルダーが構造を表すことを意味し、構造を平坦化しないことを意味します。

  +-- parent-pom (pom.xml)
       +--- module1 (pom.xml)
       +--- module2 (pom.xml)
       +--- module3 (pom.xml)

その結果、モジュール セクションの親は次のように単純化されます。

<modules>
  <module>module1</module>
  <module>module2</module>
  <module>module3</module>
</modules>

さらに、モジュールの親エントリは次のように単純化できます。

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
</parent>

...次のポイントに進みます。

現在のすべてのプロジェクトが上記のように親を定義している場合、これは単に間違っています。原因は、上位レベルのフォルダーではなく、リポジトリ内で親を見つけようとします。言い換えれば、これはリリースなどの問題の多くを引き起こしています.

この問題を修正する場合、次のようにする必要がありますが、これはお勧めできません。

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
  <relativePath>../parent-pom/pom.xml</relativePath>
</parent>

SNAPTSHOT私が観察するもう1つのことは、リリース段階でリリースプラグインに置き換えられる を使用しないことです。それに関連して、適切な親などのすべてのバージョンが自動的に変更されます。

理想的なケースでは、モジュールは次のようになります。

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
</parent>

<artifactId>module-1</artifactId>
<!-- No Version or groupId -->

すべてのモジュールがバージョンとgroupIdその親から継承するためです。モジュールを変更することが有用または必要な場合もありますgroupIdが、それは例外です。

私が読み直したのは、親の個別のバージョン管理についてです。これは単純に意味がありません。モジュールの親であるため、同じ構造、そしてもちろん同じ VCS に入れます。

いくつかの構成/プラグインのバージョンを作成したい場合、他のプロジェクトに使用する必要がある依存関係pom.xmlは、別のプロジェクトであり、個別にリリースされる別の企業を作成するなど.

構造の変更が完了したら、parent-pom ディレクトリに移動してmvn clean packageそのmvn release:prepare release:performフォルダから実行するだけで、すべてが簡単になります。

于 2012-05-04T16:57:22.877 に答える
2

POM を公開する場合は、更新をリリースする必要がありますが、POM のバージョンを手動で変更する必要はありません。バージョン プラグインまたはリリース プラグインを使用して、バージョンを自動的に更新できます。私はリリース プラグインを好む傾向があります。これは、SCM にもコミットするからです。

mvn versions:set

http://mojo.codehaus.org/versions-maven-plugin/

mvn release:prepare release:perform

http://maven.apache.org/plugins/maven-release-plugin/

リポジトリ マネージャーが既存のバージョンの上書きを許可している場合もありますが、新しいバージョンをリリースすることをお勧めします。

親フォルダーを使用して一般的なファイル (checkstyle 構成など) を保存できるため、私はフラットなモジュール構造を好む傾向があります。また、モジュール間でグループ ID を共有し、モジュール ディレクトリに artifactId と同じ名前を付けると便利だと思います。

于 2012-05-04T16:30:11.557 に答える
2

相反する要件を提示しています。プロジェクトを再構築したいが、物事を動かすことができない。展開とリリースのサイクルを簡素化したいが、単一のバージョンを使用したくない。

1 つのモジュールでの変更は必然的にすべての依存モジュールに影響を与えるため、すべてのサブモジュールが親のバージョンを継承する単純なバージョン管理スキームを使用します。maven release:準備とリリースのサイクルがシンプルになります。リリース ノートを使用して変更を追跡し、変更されていないモジュールの不要なテストをスキップすることを正当化します (バージョンを変更しても、ビルド プロセスのビルド/バイナリ出力は変更されないため、それを主な引数として使用できます)。

あなたのプロジェクトで頑張ってください。

于 2012-05-04T19:20:40.870 に答える