スライディングリリースサイクルでマルチモジュールMavenプロジェクトを適切にセットアップする方法

StackOverflow https://stackoverflow.com/questions/1210187

  •  06-07-2019
  •  | 
  •  

質問

モジュールの異なるリリースサイクルを可能にし、プロジェクトのデバッグ時に依存関係の問題が発生しないように、マルチモジュールApache Mavenプロジェクトをセットアップする最適な方法を考えています。

現在、次のラインに沿ってセットアップを行っています。

  • bigsystem@1.2
    • parent-1.1-SNAPSHOT
    • モジュールa@1.4-SNAPSHOT
      • parent@1.1-SNAPSHOTが親
    • モジュールb@1.3-SNAPSHOT
      • parent@1.1-SNAPSHOTが親
      • a@1.1に依存
    • モジュールc@1.1-SNAPSHOT
      • parent@1.1-SNAPSHOTが親
      • a@1.2に依存
      • b@1.1に依存

モジュールbおよびcで宣言された依存関係には、モジュールのコンパイルに必要な最小バージョンが含まれます。これは、必ずしもモジュールの現在のバージョンまたはデプロイされているモジュールのバージョンではありません。

ビルドの観点からこれはうまく機能し、各モジュールは必要に応じてリリース/更新できますが、IntelliJ IDEA（バージョン8および9 EAP）でデプロイされたアプリケーションをデバッグしてトップレベルのPOMを開いたとき、IDEAはa@1.2への依存関係を宣言しました。aのクラスの1つに足を踏み入れるときはいつでも、プロジェクト内の現在のa@1.4ソースではなく、a-1.2-sources.jarから開く必要があります。これは、bのクラスのいずれかにステップインすると、b @ 1.3ではなくb@1.1に移動するという事実によってさらに混乱します。

これを回避するための私の最初の試みは、親pomのdependencyManagementセクションでバージョン番号を宣言し、サブモジュールにバージョンを継承させるだけでした。依存関係管理セクションは、誰もが現在の-SNAPSHOTバージョンを指すことができるため、これはIDEAデバッグの問題を解決する程度まで機能しました。

これは、モジュールをリリースする前に親POMをリリースする必要があるため、mavenリリースを実行するときに問題を引き起こしますが、親は複数の開発中を参照している可能性があるため、SNAPSHOTSはリリースできず、最終的に追加しますリリースを満足するために、モジュールpomへのバージョン参照。

変更されたかどうかに関係なく、すべてのバンドルを同時にリリースする場合にのみ、mavenのdependencyManagementセクションを使用すると本当にうまく機能すると思われますが、必要な場合にのみ各サブモジュールのリリースを管理したいのでモデルが適合していないようです。

何か不足している疑いがあり、dependencyManagementとバージョン範囲の組み合わせが要件を満たしている可能性がありますが、バージョン範囲が適切に機能することはまだわかりません。

もっと良い方法はありますか？適切な方法？

役に立ちましたか？

解決 3

最終的に使用したソリューションは、最初に使用したものとかなり似ていました。実際のプロジェクト構造は同じままです：

  • bigsystem@1.2
    • parent-1.1-SNAPSHOT
    • モジュールa@1.4-SNAPSHOT   o parent@1.1-SNAPSHOTによってペアレント化
    • モジュールb@1.3-SNAPSHOT   o parent@1.1-SNAPSHOTが親   oはa@1.1に依存しています
    • モジュールc@1.1-SNAPSHOT   o parent@1.1-SNAPSHOTが親   oはa@1.2に依存   o b@1.1に依存
    • 配布a@1.2-SNAPSHOP

ただし、主な違いは次のとおりです。

  • 親モジュールには、プロジェクトアーティファクト
    • のバージョンは含まれません
  • 個々のモジュールはプロジェクトの依存関係を完全に宣言し、バージョン範囲を指定します（例：[1.0.0,1.1.0）
  • すべてのモジュールは、0.1からのバージョン番号サイクル、つまり1.0.1-SNAPSHOTで開始します。これにより、初期スナップショットでバージョン範囲を満たせるようになります（1.0.0-SNAPSHOTは1.0.0より前であり、最終的に含まれません）。
  • 配布pom（最初は問題に表示されていません）は、特定のリリースにデプロイ/インクルードされる exact バージョンを識別します。
  • リリース時にすべてのプロジェクト-SNAPSHOTSをローカルmavenリポジトリから削除し、ピックアップのリリースのみを範囲に指定します（または、新しいローカルリポジトリには-Dmaven.repo.local = / tmp / sometemprepoを使用します）

これにより、各モジュールがよりスタンドアロンになり、プロジェクトアーティファクトの新しいバージョンを最小限の手間でリリースおよび展開できます。

他のヒント

それらをモジュールにせず、POMを独立させることをお勧めします。そうすれば、親POMの依存関係を満たすことを心配する必要がなくなります。独立してリリースされるため、実際には独立したプロジェクトオブジェクトモデルが必要です。 Apache Commonsをテンプレートと考えてください。

IDEAの問題は、ソース構造でルートPOMを使用して、通常Mavenで相互に排他的な2つのことを行うために発生すると思います。最初にPOMを、（ビルドの観点から）無関係なMavenプロジェクトの一般的な構成情報を保存する場所として使用しています。次に、ビルドのアグリゲーターとしてPOMを使用しています。これらのそれぞれを、他を実行せずに実行できます。

ロブが言ったように、親POMのモジュールセクションからモジュールa、bなどのプロジェクトを削除します。第二に、ビルドとリリースのプロセスに関して他のモジュールの兄弟であるため、親POMを独自のディレクトリに移動します。あなたが今持っている方法、それはより親/アグリゲーターです。

現在の方法では、親POMのタグにすべてのモジュールサブフォルダーが不必要に含まれる可能性があるため、各モジュールに個別にタグを付けたり解放したりすることはできません。

ファイル構造は次のようになります。

  • 親
    • pom.xml
  • モジュールa
    • pom.xml
  • モジュールX
    • pom.xml

不足しているものに関しては、dependencyManagementはプロジェクト内の依存関係のバージョンを管理するのにはあまり適していません。それは、集約されたビルド内のモジュール間の依存関係です。外部依存関係のグローバルバージョンを宣言するのにより適しています。

これらは確かに別個のモジュールのように見えます。マルチモジュールプロジェクト内であっても、異なる依存関係がある場合、それらを一緒に壊すことによってどのような利点が得られますか？

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top