7

私の通常のやり方は、次のように svn トランクごとに単一の maven プロジェクト (マルチモジュールにすることができます) を持つことです:

trunk/ (style 1)
  /pom.xml
  /submod-1
  /submod-2

基本的に、トランク全体が単一のリリース パッケージとして扱われます。これは管理しやすいと思います。このトランク内のすべてのモジュールを管理するための集約/親 pom があります。

しかし、私は仲間の何人かが次のように組織していることに気付きました:

trunk/ (style 2)
  /project-1
    /pom.xml
  /project-2
    /pom.xml

基本的に、単一の svn トランク内で... project-1 と project-2 は別々に管理する必要があります。つまり、トランクをチェックアウトして、その内容を単一のマルチモジュール Maven プロジェクトとして操作することはできません。これはありがたいことです。

Q1: スタイル 2 が適しているのはいつですか?

Q2: Subversion を使用して Maven プロジェクトを管理する方法について、ベスト プラクティスを教えてもらえますか?

4

4 に答える 4

2

私は@Raghuramの答えにほぼ同意しますが、以下を追加したいと思います：

  • プロジェクトを同じライフ サイクルと同じバージョン番号で一緒にリリースする場合は、トランクのルートに親 POM があるスタイル 1 が必要です。通常、この親 POM には、ルートから構築されるモジュールとしてサブプロジェクトが含まれます。
  • スタイル 2 は、一連の独立したプロジェクト (ユーティリティなど) があり、単一の SVN の場所 (管理を容易にするため) が必要であるが、リリース サイクルが異なる場合に適しています。この場合、単一のプロジェクトをmodulesとして含むルート アグリゲーター POM は必要ありません。コンパイラ設定やプラグイン管理などを一元化するユーティリティ プロジェクトに共通の親 POM を用意することは、依然として理にかなっている場合があります。スタイル 1 との違いは、すべてのプロジェクトをまとめてリリースしないことです。親 POM だけの安定バージョンをリリースしてから、必要に応じて単一のユーティリティ プロジェクトをリリースします。

私たちは両方のスタイルを使用して大きな成功を収めました。主な違いは、リリースに使用する方法と頻度にあります。

スタイル 2 (およびユーティリティ プロジェクトの例) では、これらのプロジェクトが同じ SVN タグとトランクを共有していても問題はありません。開発者は、ユーティリティ トランク全体をチェックアウトするか、1 つのプロジェクトだけをチェックアウトするかを決定できます。

于 2012-06-12T06:15:24.680 に答える
2

私は両方の例を見てきました。

私の意見では、プロジェクト/モジュールがどれほど独立しているかに依存します。独自のリリース計画がある場合、独自のトランク、ブランチ、およびタグを持つことは理にかなっています。ただし、プロジェクト/モジュールが常に一緒にリリースされる場合は、それらが単一のトランクの一部であることが理にかなっている場合があります。

Maven の観点から、マルチモジュール プロジェクトのモジュール<version>が親から継承する場合は、style 1上記に従う必要があります。

于 2012-06-12T04:54:39.280 に答える