問題タブ [multi-module]

Mavenマルチモジュラープロジェクトがあります。構造は次のようになります。

パッケージ定義は次のようなものです。

モジュラスの1つ（ModulA）は同じ階層レベルを持ち、もう1つは親モジュラスにあります。Jenkinsにジョブを追加して、すべてを自動的にビルドしようとしています。（クリーンパッケージ）。

parentModulが他のモジュールを見つけてプロジェクトをビルドするジョブをどのように構成する必要がありますか？

かなりの数のサブモジュールを持つMavenプロジェクトがあります。私が探しているのは、集約POMの/ target /ディレクトリに含まれているサブモジュールによって生成されたすべての.jarファイルを取得して、後で便利に使用できるようにする方法です。

• それらをマージする必要はありません。できればそうではありませんが、そうでなければならない場合は問題ありません。
• 依存関係を気にしないでください
• これは主に便宜上のものであり、現時点では

私がやろうとしていることの基本的なバージョン：

私は読んでいて、SOからのいくつかの提案も使用しています。これまでのところ、これを行う方法は見つかりませんでしたが、確かにあります。

編集：

含まれているすべてのサブプロジェクトについて、これを簡単な方法で機能させることを諦めました。私がこれまでに得た最善の答えは、依存関係プラグインを使用して、含めるすべてのサブモジュールを手動で（再度）指定することです。アイデアは、必要なモジュールを含めるだけで、すべてのサブモジュールのjarを1つの場所に魔法のように貼り付けることで、数十のクライアントに対してPOMを簡単に構成できるようにすることでした。Mavenは、あまり何もしない場合はかなりいいですが、試してみるとアングルブラケット税は信じられないほどです。

そのような標準的なタスク（SOで尋ねられた質問から判断すると、通常のプロジェクトで何が行われるか）が非常に難しいのはまだ奇妙だと思います。maven3の方が良いですか？

Mavenを使用したソフトウェアバージョニングおよびマルチモジュールプロジェクトのベストプラクティスは何ですか？

つまり、Mavenを使用してマルチモジュールプロジェクトを作成する場合、バージョン管理に最適なアプローチは何ですか？すべてのモジュールに単一のバージョンを使用するには（最上位のプロジェクトで定義）？各モジュールのバージョン（各モジュールのPOMで定義）を使用するには？私が見逃している別のアプローチはありますか？各アプローチの長所と短所は何ですか？

一般に、異なるモジュールは一緒にリリースされますか（おそらく同じバージョン番号を共有します）？

ありがとう

同じデータ モデルに依存する複数のプロジェクトがあります。後者は Maven プロジェクトによって定義されます。例として、それぞれ複数のモジュールを含み、このデータ モデルに依存する 2 つの複合プロジェクト A と B を考えてみましょう。プロジェクトAとBは関係ありません。

この場合の最善のアプローチは何ですか？A と B が依存する独立したプロジェクトとしてデータ モデルを残すには? または、データ モデルをモジュールとして定義し、それを 2 つの複合プロジェクト A と B に含めます (モジュールが多くのプロジェクトで共有されるかどうかはわかりません)。

ありがとう

大きなマルチモジュールプロジェクトがあり、MavenにSCM情報を指定したいと思います。ただし、各モジュールと親プロジェクトにはSVNに専用のフォルダーがあるため、SCM情報は各モジュールに固有のようです。

connection要素とdeveloperConnection要素に使用する必要がある値はどれですか？モジュールごとにSCMを構成する必要がありますか、それとも親プロジェクトで1回構成できますか？

ありがとう

私は次の構造を持っています：

共通モジュール

• 共通モジュール関連のサービス、および永続化 API が含まれています。
• 共通持続性コンテキストtest-common-persistence-context.xmlが含まれています。

search-module (共通モジュールに依存)

• 検索モジュールに関連するモデル Bean (JPA エンティティ アノテーションでマークされている)、サービス、および永続化 API が含まれています。
• 検索モジュール関連のスプリング コンテキスト ファイルが含まれています

予約モジュール (共通モジュールに依存) - 予約モジュールに関連するモデル Bean (JPA エンティティ アノテーションでマークされている)、サービス、および永続化 API が含まれます - 予約モジュールに関連する Spring コンテキスト ファイルが含まれます

common-module にはtest-common-persistence-context.xmlがあります。タイプがorg.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBeanのsessionFactory Bean の場合、プロパティ「packagesToScan」の値を JPA が含まれるパッケージに設定する必要があります。モデル Bean とマークされたエンティティ アノテーションが存在します。それがないと、例外Unknown entity: MY_ENTITY_NAMEが発生します。

共通モジュール: test-common-persistence-context.xml

私の共通モジュールにはJPAエンティティがないため、スキャンするパッケージがないため、「packagesToScan」プロパティ値を空のままにします

ただし、それぞれのモジュールの JPA エンティティが検出されるように、検索モジュールと予約モジュールのテスト ( SearchPersistenceTestBase.java ) で同じ永続化コンテキストを使用する必要があります。

検索モジュール: SearchPersistenceTestBase.java

上記のセットアップでこの望ましい動作を実現する方法を教えてください。

**私が試したアプローチ**

プロパティファイルから値が設定される追加の java.lang.String タイプの Bean を使用することを考えました

test.packages.to.scan.jpa.annotationsは、test-common-persistence-bundle.propertiesで空として定義されています。

そして、test-search-spring-context.xmlの Bean 定義をオーバーライドします。

test-search-spring-context.xml

test.packages.to.scan.jpa.annotationsは、 test-search-bundle.propertiesで「com.search.model」として定義されています。

しかし、これは機能せず、例外Unknown entity: MY_ENTITY_NAMEが発生しました

ありがとう、
ジグネッシュ

社内フレームワーク プロジェクトの 1 つを ant から maven に変換し終えたところです。Maven ビルドは正常に実行され、問題なくリポジトリにデプロイされます。

問題は、他のプロジェクトがフレームワークを使用しようとすると、機能しないことです。ダウンロードされるのは、最上位のフレームワーク pom だけです。

さまざまなモジュールの 1 つまたは複数にいくつかの依存関係エントリを追加しようとしましたが、どれを追加しても循環依存関係エラーが発生します。また、モジュールがなく、いくつかの依存関係を持つ 2 番目のトップ レベルの pom ファイルを作成して、リポジトリ マネージャーのファイルを上書きしようとしました。これにより、一部の依存関係がダウンロードされますが、maven ビルドはランダムな場所でハングします。Windowsタスクマネージャーに基づいて、無限ループにあるように見えます。したがって、2番目のpomファイルは答えではないようです(または間違っています)。

私のフレームワーク pom ファイルは次のようになります。

次に、最上位の pom の通常のプロパティ、依存関係管理、および pluginManagement エントリ。

消費モジュールには、次のものがあります。

これは最上位の pom にあるため、すべてのサブモジュールがフレームワーク ライブラリにアクセスして、開発者にとってより簡単になります。

依存するすべてのjarファイルが消費プロジェクトによってダウンロードされるように設定するにはどうすればよいですか?

Eclipseプラグインのプロジェクト、機能、更新サイトがたくさんあります。モジュールを定義するマスターpomを作成しました。

この順序を保持したかったので、複数のモジュールを操作するためのガイド に従って、上記のリンクに従って、モジュール要素がリストされた順序に従って順序が保持されると想定しました。

要件：site1はsite_assembly.zipを生成します。このzipファイルを取得して、「b2」バンドルが行うバンドルにラップアラウンドしたかったのです。

私たちの観察：

1. マルチモジュールビルドの開始時に出力されるMavenリアクターの順序は適切ですが、すべてのモジュールのビルドはフォークされます。
2. （1）バンドルb2は、site1プロジェクトがビルドされる前にビルドされ、サイトアセンブリzipを生成できます。
3. 「b2」のpom.xmlの依存関係をsite1に追加しようとしましたが、これまでビルドされていないsite1に依存関係があるb2を最初にビルドしようとしたため、ビルドが失敗しました。
4. ユニットテストを行ったときに、osgiフラグメントと同じ動作が観察されました。ホストがテストフラグメントの前に来ることを明確に指定した順序で、Mavenビルドが呼び出されると、常にホストの前にフラグメントがビルドされ、失敗していました。

マスターpomで定義されているプラ​​グイン：

maven-tycho-pluginが原子炉の順序に干渉するかどうかはわかりませんので、助けていただければ幸いです。

Maven アセンブリ プラグインを使用して、マルチモジュール プロジェクトのアセンブリを作成します。このマルチモジュール プロジェクトからビルドされた 2 つの個別のアプリケーションがあり、それぞれに個別の依存関係があります。モジュール ビルドとそれぞれの依存関係を使用して (アプリケーションごとに) 2 つのディレクトリをアセンブルするカスタム アセンブリ記述子を作成しました。それはすべてうまくいきますが、1 つのこと - 両方のモジュールの依存関係を互いのアセンブリに置きます。

以下は、まったく同じ動作をする私のプロジェクトの簡略化されたバージョンです。

2 つのモジュールと 1 つのアセンブリ モジュールで構成されるプロジェクトを考えてみましょう。

純粋にデモンストレーションのために依存関係を追加しました。

親POMは次のとおりです。

モジュール 1 POM:

モジュール 2 POM:

アセンブリ POM:

最後に、アセンブリ記述子:

ご覧のとおり、アセンブリはパッケージ フェーズにバインドされます。だから、私が実行すると

親ディレクトリから、次のアセンブリがあります

基本的に、ここでの問題は、module1 が commons-daemon に依存していないことですが、アセンブリ プラグインには依存関係が含まれています。同様に、module2 と commons-cli を使用します。

アセンブリプラグインがこのように動作する理由を誰かが説明できますか?

解決策は何ですか？

これは ear プロジェクトの単純化された例です。親 pom は EAR、EJB、および jar を集約します。

私はSVNに保存されたMavenプロジェクトにこの構造を持っています:

modulB には modulA の依存関係があります

pom.xml にはモジュールセクションがあります

そして、依存関係管理セクション

サブモジュールは親を参照します

maven 2.2.1（Windows）で初めてコンパイルしたときのPCで

問題はありません

しかし.... Jenkinsが初めてコンパイルしようとしたとき（Maven 2.2.1 Linux RedHat）

どうして？？？？？？？？

その後、PC から Artifactory にプロジェクトをデプロイすると、Jenkins はリポジトリからアーティファクトをダウンロードするため、Jenkins には問題がありません...しかし、なぜ Jenkins はリポジトリ内のアーティファクトに依存するのでしょうか?

:(

前もって感謝します

編集：

dependencyManagement セクションは依存関係を「定義」するだけだと思いましたが、サブモジュールが依存関係を使用しない場合、依存関係はサブモジュールに追加されません。dependencyManagement セクションを削除しても、Jenkins の問題は引き続き発生します。

私のPCでは問題なく動作します。