問題タブ [multi-module]

コンテクスト

• マルチMavenモジュールまたはシングルMavenモジュール構造の大きなプロジェクト

質問

• 最終的にmulti-maven-moduleまたはsingle-maven-module構造を使用しましたか？

詳細

開発期間が長く、多くの機能を含む大きなプロジェクト（つまり、些細なプロジェクトではない）に取り組んだ場合、プロジェクトを複数のMavenモジュールに分割することを選択しましたか、それとも単一モジュールのアプローチを採用しましたか？

たとえば、マルチモジュール構造の場合、mvn gwt：eclipseなどのmavenコマンドを実行するとクラッシュします（http://bit.ly/gs4Rmoを参照）。これは、単一モジュールのGWTプロジェクトでうまく機能したと思います。また、マルチモジュール構造に問題がある上記のような他のコマンドが存在する可能性があります。

ただし、マルチモジュール構造は、開発の高速化のメリットをもたらす可能性があります。つまり、「サーバー」を「クライアント」モジュールから分離すると、ビジネスロジック（サーバー）を個別にコンパイルして、結果のWebアーカイブにパッケージ化できます。GWTコードのコンパイルには約20秒かかるため、サーバーパッケージのみを変更すると、長期的には多くの時間を節約できます。

マルチモジュール/シングルモジュールプロジェクトで作業しているときに、上記のような他のどのケースに遭遇しましたか？

ありがとうございました！

Maven 2マルチモジュールプロジェクトがあり、すべてがローカルのチェックアウトされたソースから取得されていることを確認したいと思います。

• ソースを持っているモジュールには何もダウンロードしないようにMavenに指示することは可能ですか？リモートリポジトリを無効にする必要がありますか？
• Mavenは常に、モジュールをローカルリポジトリにインストールし、その依存関係ごとにモジュールを再度抽出するという高価な方法をとる必要がありますか？
• ローカルソースが変更された場合、Mavenは最初にモジュールの依存関係を自動的に再コンパイルし、次に依存関係をコンパイルしますか？

大量のMavenアーティファクトで構成されるかなり大きなJavaアプリケーションがあります。各サブシステムは、サブバージョンツリーにtrunk /、branchs /、tags /サブフォルダーを含む独自のフォルダーを持ち、複数のアーティファクトをホストします。MavenPOMの階層には複数のレベルがあります。依存関係管理でさえ、異なるモジュールに分割されます。アプリケーションは、複数のWARおよびその他のZip/JARのものとしてデプロイされます。

それを構築してデプロイする過程で、私はしばしばアプリケーションを1つのユニットとして見なければなりません。そして、私はここで共有したいたくさんの困難に遭遇しました。

1. Subversionレイアウト：1つのコマンドでコードベース全体をチェックアウトすることはできないという事実から始まります。トップレベルから始めて、すべてのサブプロジェクトからすべてのブランチをチェックアウトすると、単純に大きすぎて時間がかかりすぎます。アーティファクトの数を減らすことは、根本的な変更が多すぎるため、現在のところ実際にはオプションではないと思います。しかし、集約されたブランチフォルダを使用した別のSubversionレイアウトが実際に役立つ可能性があります。私が試した回避策の1つは、適切なサブフォルダーをまとめた、多数のSubversion外部を含む別のフォルダーを作成することです。次に、たとえば、トップレベルのマルチモジュールアーティファクトから1つのmavenコマンドを使用してすべてをビルドできます。

2. リリース：リリースはコードベース全体で行われます。最初に、プロジェクト用に特別に作成されたカスタムツールを使用する巨大な依存関係グラフを作成します。これは、Mavenで直接行うことはできないためです。次に、依存関係ツリーのアーティファクトの1つのレイヤーを段階的にリリースする必要があります。最初に、依存関係のないアーティファクトを作成し、親POMを新しいバージョンにうまく適合させた場合は、それらをビルドして、次のレイヤーに進みます。 。時々、すべてのバージョン管理作業を2回、1回はSubversionで、もう1回はすべてのPOMで実行したいと思うことがあります。リリースプラグインは、依存関係管理を自動的に適応させることもできないようです。

3. ハドソン：ハドソンでは、すべての親アーティファクトに対して20のジョブがあります。また、アーティファクトごとに3つのアクティブなブランチがあります。これは60の仕事のようになります。ブランチが変更されるたびに、ブラウザで多くのマウスクリックが発生します。少なくとも、依存ジョブの自動ビルドトリガーは機能しています。ただし、モジュールがコンパイルジョブとレポートジョブに分割されている場合は、これも問題を引き起こします。通常、コンパイルはレポートの生成よりもはるかに頻繁に行われ、後者は前者の速度を低下させるべきではありません。ただし、レポートジョブが実行されるたびに、すべてのコンパイルジョブもトリガーされます。アーティファクトが実際にデプロイされている場合、ハドソンは依存ジョブのみをトリガーできないようです。また、プロジェクト全体に対して1つの巨大なマルチモジュールビルドを作成しようとしましたが、インクリメンタルビルド機能が正しく機能しません。そして、それがないと、ビルドに時間がかかりすぎます。ただし、依存するアーティファクトを構築する必要があります。これは、1つのアーティファクトがどのような変更を引き起こすかを確信できないためです。

4. 集計レポート：親POMの各レベルについて、単体テスト、テストカバレッジ、チェックスタイルなどの集計レポートを生成する方法をまだ理解していませんでした。一部のプラグインは、集約オプションをサポートしていません。他の人のために、私は階層の各レベルに対して再度ビルドを行わなければなりません。Mavenサイトのレポートは問題ありませんが、かなり静的であり、閲覧時に使用できるのは限られているようです。おそらく、ここでのより良いオプションは、SonarSourceやその他のソースコード分析ツールのようなものを使用することです。また、これらのレポートをハドソンに統合することは私には理想的ではないようです。

私の観点からは、1つのディレクトリをチェックアウトし、ソースからすべてを構築し、リリース用に1つのタグ/バージョンを作成し、外部リポジトリに依存せず、Hudsonで1つのジョブを構成できる大きなリポジトリを1つだけ作成したいと思います。しかし、これはおそらく、さまざまな開発者チームが必要としているものとはかけ離れています。どういうわけか、両方の管理可能な方法を見つけるのは難しいようです。

既存のMavenプロジェクトがあります。m2eclipseプラグインでインポートしましたが、プロジェクトを実行できません。Tomcatはリソース（ターゲットフォルダの下のWARファイル）を見ることができません。私は何が欠けていますか？ところで、マルチモジュールプロジェクト（2つのWARファイル）があります。

前もって感謝します！

Rubyで使用するための「Equinox (OSGi)」のような実装はありますか?

Ruby で簡単に管理できる分散マルチモダリティを使用したいのですが、E のようなものを見つけることができませんでした

Mavenに関する実行可能性に関する質問です。特に、集約pomでプロパティを定義し、それらを参照されるモジュールに挿入して、そのモジュールが継承階層で定義されたデフォルトのプロパティをローカルで上書きできるかどうかについて。

詳細に興味がある場合は、セットアップについて説明します。ただし、その前に、プロジェクトの構造についてチームとして幅広く話し合い、ニーズに非常によく適合していることをお伝えしておきます。現時点では、他の構造に関する提案を探しているわけではありませんが、Mavenが私たちのニーズを満たすことができるかどうかだけを調査しています。

だから、私たちのセットアップ。私はそれを本質に要約します。AとBの2つのソースプロジェクトがあります。これらはそれぞれ、実際にはそれぞれParentAとParentBの子モジュールです。ParentAとParentBには技術的には多数の子モジュールがありますが、この例では、簡単にするためにそれぞれを明示的に参照します。ここまでは順調ですね。ParentAはAをサブモジュールとして参照し、AはParentAをその親として参照します。同じ関係がBとParentBにも当てはまります。

今、楽しみが来ます。ParentAとParentBの両方のスーパー親pomが、dependencyManagementやプラグインなどの共有プロパティと構成を継承するようにします。ただし、このスーパー親pomがビルドを担当することは望ましくありません。代わりに、さまざまなモジュールを選択的にビルドするいくつかのビルドプロジェクトを定義したいと思います。この例では、BuildABとBuildBを紹介します。最初のビルドはA、次にBをビルドしますが、2番目のビルドはBだけです。実際には、これらのインターリーブモジュールグループと依存関係がかなりあります。最後に、全体像を完成させるために、BからAへの依存関係があります。

アスキーアートを使ってこれを描いてみましょう;）

継承

サブモジュールの関係

依存関係

現在、BuildABファイルとBuildBファイルのプロパティを使用して依存関係を定義することは不可能です。これらのビルドファイルは継承ツリーの一部ではないため、プロパティを取得するものはありません。ただし、BuildABとBuildBを実行する場合は、依存関係のバージョンを異なる方法で制御する必要があります。依存関係をスーパーペアレントに配置するだけでは、要件に合わせて依存関係を削減することはできません。

なぜこれが考えられるのか疑問に思っている場合は、1つのチームがBモジュールを開発しており、Aにも小さな変更を加えている可能性があります。他の開発者は、依存関係のおかげでBに影響を与えるプロジェクトAの最新かつ最高のものに取り組んでいる可能性があります。Mercurialのおかげで、これをソースコードで処理するための優れたメカニズムがあります。しかし、Mavenでこれを機能させるのに本当に苦労しています。

理想的には、各ビルドファイルは、最初に親から継承するサブモジュールに依存します。ただし、この継承をオーバーライドする必要がある場合は、ビルドファイルで注入可能なプロパティを指定できるようにします。これは、モジュールで最初に指定された場合とまったく同じように機能します。もちろん、ソース制御されているpomを実際に変更することなくすべて。

評価したいのは、プラグインまたはパッチを介して、これを行うためにMavenを変更する余地があるかどうかです。

私たちはこれまでプラグインを書いたことがありません（そして率直に言って、これに関するチュートリアルやオンラインのものは乏しく、実際には開発者に優しいものではありません-誰かが私が見逃した良いチュートリアルを持っていない限り:)）それは実行可能のようです。

だから基本的に、

• 以前に同様の要件を自分で処理し、既存のプラグインで機能させたことはありますか？
• 私たちが見逃している簡単なトリックはありますか？
• 同様のプラグインを作成し、開始する場所を推奨できますか？
• そのようなプラグインが機能しない可能性がある実際的な理由を知っていますか？
• Mavenのソースコードに取り組んでいて、結果のコードを提供できるかどうかを知っていますか...そして、必要に応じてどこから始めればよいのでしょうか。

最後のコメント。私たちはEclipseで開発しているので、プロパティを挿入せずに動作するビルドも必要です。これは通常の継承ツリーを介して行われると思います。

どうもありがとうございました。少し難しい質問だと思います。

私は次のようなマルチモジュールプロジェクトを持っています
---モジュールA（戦争を構築します）
---モジュールB
---モジュールC

マルチモジュールプロジェクトを構築するために、モジュールを定義するアグリゲーターPOMがあります。
<modules>
<module>C</module>
<module>B</module>
<module>A</module>
</modules>

WARファイルAは、モジュールBとモジュールCに依存しています。

アグリゲーターpomを構築するとき、特定のプロファイルでモジュールBを構築したいと思います。特定のプロファイルでモジュールBを構築するようにアグリゲーターpomに指示する方法はありますか？

以下に示す親/子構造を持つマルチモジュールMavenプロジェクトがあります。

| 親->pomパック| --submoduleAppletUtils->jarパック| --submoduleAppletA->jarパック| --submoduleAppletB->jarパック...| --submoduleAppletN->jarパック

各アプレットjarは、submoduleAppletUtilsクラスに依存しています。以下に示すmaven-jar-pluginを使用して、これらの各jarpomファイルのマニフェストクラスパスエントリを含めています。各jarをビルドするときに、submoduleAppletUtils関連のjar/クラスは生成されたjarのいずれにも含まれていません。実行時にそれらを利用できるようにするために、それを達成する方法を考えています。

-前もって感謝します。

私はこの概念に慣れていないので、「マルチモジュールプロジェクト」と呼ぶのは間違っているかもしれません。私が作成しているソフトウェアには、異なる入力と出力を持つ1つの異なるユニットがあります。このスタンドアロンモードでは他の値があるため、これを引き出して別の（Web）サービスとして実行することにしました。

ただし、以前はこのユニットとブレンドされていたアプリケーションもスタンドアロンで実行する必要があります。つまり、サービスエンドポイントを呼び出すことで、そのユニットと通信するための新しい方法が必要になります。これにより、複雑さの新しいレイヤーが追加されます（それほど単純ではないデータをXMLとJSONにシリアル化および逆シリアル化）。ソフトウェアエンジニアリングでこれに共通する慣習はありますか？他の方法でデータを送信できますか？

ソフトウェアはJVM上で実行されるScalaで書かれており、このストーリーに影響する場合と影響しない場合があります。