6

次のような Maven プロジェクト インフラストラクチャがあります。

/trunk/all/pom.xml
/trunk/all/libs/lib1/pom.xml
               /lib2/pom.xml
               ...
/trunk/all/projects/p1/pom.xml
                   /p2/pom.xml
                   ...

ご覧のとおり、私は多くのライブラリと、これらのライブラリを使用する多くのプロジェクトを持っています。

私は好きなので、これらすべてが1つのマルチモジュールプロジェクトに結合されています

  • トッププロジェクトをEclipseにインポートし、すべてのライブラリとプロジェクトを一度に利用できるようにします
  • mvn testいくつかのグローバルなリファクタリングを行った後、すべてのコードをコンパイルしてテストするために1 回だけ実行します。

現在、私のモジュールはすべて version1.0-SNAPSHOTです。

今、私はプロジェクトp2をリリースしたいと思います. その後、 でいくつかのコード変更を行いますが、ではありません。p2lib1lib21.0lib1lib2

私は version であり、 in version (最後のリリース以降に変更された) を使用する次のリリースが必要ですp2が、まだ1.1version (変更されていないため) です。lib11.1lib21.0

より一般的なこと: リリースを行う場合、リリースされるプロジェクトのマイナー番号と、最後のリリース以降に変更されたすべてのライブラリのマイナー番号を増やしたいと考えています。

質問

すべてのモジュール バージョンを自分で処理する必要がありますか? それとも、必要な作業を実行できるプラグインがありますか?

4

2 に答える 2

8

すべてのモジュール バージョンを自分で処理する必要がありますか? それとも、必要な作業を実行できるプラグインがありますか?

さまざまなアーティファクト (プロジェクト、ライブラリ) のバージョンを で定義されているバージョンと同期させたくない場合all/pom.xml(つまり、階層全体で継承するだけ)、残念ながら、次のことを開始する必要があります。それらを手動で管理します。変更を加えていなくても、バージョンを上げない理由がよくわかりませんlib2。現在の svn リポジトリ構造では、すべてのアーティファクトはどういうわけか同じリリース ライフサイクルを持っています (トランクにタグを付けると、その中のすべてにタグを付けます)。

さて、p1（p2簡単にするためにライブラリは無視します）が独立したリリースサイクルを持っている場合、このスレッドで説明されているように、複数の「トランク/タグ/ブランチ」構造をお勧めします：

myrepo
  + .links (2)
    + trunks
      + pom.xml
  + parent-pom (1)
    + trunk
      + pom.xml
  + project-A
    + trunk
      + pom.xml
  + project-B
    + trunk
      + pom.xml

1) プロジェクトの親 POM には、独自のリリース サイクルがあります。すべてのコンポーネントの POM は、それを親として使用します (単純にgroupIdand artifactId、 noで参照されrelativePathます)。リリースの場合、最初に親 POM をリリースする必要があります。

2) これは、プロジェクトの特定のブランチ (通常はトランク) を簡単にチェックアウトできるようにするための構造です。Subversion ユーザーは myrepo/.links/trunk をチェックアウトして、すべてのソースの最新リビジョンを取得します。秘訣は、そのディレクトリに svn:externals、このプロジェクトの他のすべてのモジュール (parent-pom、project-A、project-B) のトランクへの外部リンク (つまり、プロパティを含む) が含まれていることです。このディレクトリの pom.xml は決してリリースされません。これには、マルチ モジュール ビルドを有効にする 3 つのモジュールのモジュール セクションが含まれているだけです。このコンストラクトを使用すると、ブランチを簡単にセットアップできます。

myrepo
  + .links
    + branch-2.x
      + pom.xml

私はこのセットアップを何度も使用してきました (私はすでに SO でそれについて書いています。以下の関連する質問を参照してください)、非常にうまく機能します。実際、Maven を含む多くのプロジェクトがこのアプローチを使用していますが、これはファンタジーではありません。

これはあなたの "automagic" バージョン処理を解決しません (私はその解決策を知りません) が、少なくとも、この構造はMaven リリース プラグインとうまく連携し、独立したリリース サイクルの要件をサポートします。

こちらもご覧ください

関連する質問

于 2010-10-27T23:44:27.907 に答える
1

こんにちは！何かが足りないかもしれませんが、ライブラリ/モジュールが独自のバージョン番号を持つ必要性を感じ始めた場合、それは彼らが成長し、独自の人生を歩んでいることを示しているのではありません-つまり、別々のプロジェクトになっています自分の権利で？

それらをそのように扱うことは理にかなっているかもしれません-それらを別々のプロジェクトとして扱い、いくつかのmvnリポジトリにプッシュし、通常の依存関係としてコアプロジェクトに追加しますか？

どういうわけか要点を見逃してしまったら申し訳ありませんが、私はマルチモジュールプロジェクトの「問題」に自分自身で遭遇しています....そしておそらく問題は実際にはまったく問題ではありませんか？

于 2011-01-21T08:19:31.183 に答える