問題タブ [multi-module]

いくつかの子モジュールを持つ親POMがあります。これらの1つとして、ビルドの下にantrunセクションを追加しました。現時点では、これは単にステートメントを出力します。この子モジュールは、セット全体で他のモジュールに依存しています（したがって、親には1〜8の子が8つあり、このモジュール（＃5）は2と3に依存します）

antrunセクションの形式は次のとおりです。

親モジュールの下でアクション（たとえば、検証またはインストール）を実行すると、これらは正常に機能し、予想どおり、このantrunタスクを保持する子（＃5）に対してechoステートメントが実行されます。

ただし、子モジュールに移動してそこからmvn validateを試してみると、（凡例）が取得されます。

失敗。しかし、すべてのモジュールは私のローカルリポジトリに存在し、最新のものです。そして、mvn installを再度実行するというこの問題の通常の修正では、修正されません。

他の誰かが（何がうまくいかないのか）知らない限り、それは私にはバグのように見えます。

クリス

m2e (Maven 3.0.3 の外部バイナリに接続) で Eclipse Indigo を使用しています。

現在、私のアプリケーションの意図した構造は次のとおりです。

Company-parent が Project-parent のプロジェクトになり、Project-parent がすべてのモジュールの親になるように pom を設定しました。会社の親とプロジェクトの親は問題ないようです。どちらもパッケージタイプのPOMです。

3 番目のレベルでは、問題に遭遇し始めます。最も単純なモジュール プロジェクトが定義されていても、さまざまな Maven エラーやあらゆる種類の奇妙な動作が発生します。

親会社:

プロジェクトの親:

モジュールポン:

「Maven -> Update Project Configuration」を実行すると、次のエラーが発生するため、実行できません。

私が受け取っている他のいくつかのエラー：

また、モジュール内の (会社レベルの pom からの) プラグインの目標の 1 つを無視する m2e に関するエラーを受け取ります。ここで明らかな何かが欠けていますか？ヘルプ！

ありがとう ：）

私は、Google コード (SVN) と ANT (ビルド タスク用) から git (GitHub) と maven に移動されたオープン ソース プロジェクト ( ps3mediaserver ) に参加しています。私は独自のフォーク (pms-mlx と呼ばれる) を持っており、リリース時にいくつかのプラグインをデフォルトのパッケージの一部として維持したいと考えています。私はMavenにかなり慣れていないので、Mavenの方法を尊重するためにプロジェクトをどのように構成する必要があるのか​​ よくわかりません。
環境が以前にどのように動作したかを説明することから始め、次に Maven への移行についての考えを述べます。

リンク:

• 旧: Google コードの SVN + ANT ps3mediaserver プロジェクト
• 旧: SourceForge の SVN + ANT pms-mlx プロジェクト
• 新規: GitHub の Git + Maven ps3mediaserver プロジェクト
• 新規: GitHub の Git + Maven pms-mlx プロジェクト

古い動作:

プロジェクトの構造:

メイン プロジェクトは ps3mediaserver_mlx で、すべてのプラグインはワークスペース/プラグイン フォルダーのサブフォルダーにあります。
ps3mediaserver_mlx/build.xml には、メイン プロジェクトの jar をビルドし、プラグインによって (この場所で) 参照される workspace/pms_no_libs.jar にコピーするターゲット BuildWithoutLibs が含まれています。
任意のプラグインのビルド ターゲットを実行すると、プラグインがビルドされ、結果の jar が ps3mediaserver_mlx/plugins/[plugin_name].jar にコピーされます。
最後に、ps3mediaserver_mlx/build.xml のビルド ターゲットを使用してアプリケーションをパッケージ化すると、workspace/ps3mediaserver_mlx/plugins に含まれるプラグインがパッケージ化されます (Windows の場合は exe インストーラー、OSX の場合は dmg、Linux の場合は tar.gz)。

新しい動作 プロジェクト構造は次のように変更されました。

責任:
global-pom pms によって使用されるすべての依存関係を含むルート pom。これにより、どのプラグインでも再宣言せずに同じバージョンを使用できます (これは良い考えですか?)。すべてをビルドし、すべてのプロジェクトで同じ Maven コマンドを実行するモジュール セクションを含む

pms-pom : global-pom から継承し、pms jar をビルドします

plugins-pom : global-pom から継承します。pms の依存関係が含まれています (すべてのプラグインに必要です); ビルドする必要があるすべてのモジュールのリストが含まれています

pluginX-pom: plugins-pom から継承し、プラグインのカスタム構成を含みます

package-pom : ビルドされているプラ​​ットフォームに従って pms をパッケージ化する責任があります。

この構造は、maven の使用方法を表していますか?

すべてがパッケージングまで機能しています。これは、メイン アプリケーション jar とすべてのプラグインがビルドされ、パッケージ化する必要があることを意味します。package-pom はそれを行う責任があります。
元のアプリケーションにはpom.xmlが1 つしかなく、Windows、Linux、OS X 用に異なるプロファイルを使用してパッケージ化が行われています。ソース コードがアプリ ファイルにパッケージ化されることはありません。これは、パッケージ化プロジェクトが実際のプロジェクトから継承されなくなったためです。
アプリ ファイルに正しくパッケージ化するために、ビルドされた jar をどのように参照する必要がありますか?
additionalResources およびカスタム クラス パスとして jar を参照しようとしましたが、成功することはありませんでした。

2 つの子サブモジュールのバージョン、プラグイン、および依存関係の定義を収集するスーパー POM があります。

ディレクトリをサブモジュールの1つに変更する限り、これは正常に機能します。ただし、親 POM で jetty:run または liquibase:update を実行すると、プラグインの実行が対応するサブモジュールに「転送」されるのを確認したいと思います。

そのようなことが達成できるかどうか、何か考えがありますか?

前もって感謝します、

ロルフ

PS:更新が遅くなり申し訳ありません

親POM

データベースの移行

ウェブアプリ

Maven マルチモジュール プロジェクトがあり、このビルドには 2 つの異なる親 POM が必要です。最初のものはプロジェクト内のほとんどのモジュールの実際の親 POM ですが、1 つのモジュールは完全に異なるプロジェクトの親 POM を使用するデモ プロジェクトです (これは私のプロジェクトを使用して 2 番目のプロジェクトのコードを生成する方法のデモであるため)。

ビルドは機能しますが、警告が表示されます。

other_project実際には私のビルドのモジュールではないため、どこにでも配置できます。これは、相対パスを指定できないことを意味します。

この警告を修正するにはどうすればよいですか?

マルチモジュール プロジェクトの基本構造を作成しました。私は別のマルチモジュール プロジェクト ベース コード (他の誰かによって作成されたもの) を持っていますが、これは似ていてうまく動作します。両方のプロジェクトには、同じモジュールと同様の POM があります。どちらもエンタープライズ プロジェクトであり、どちらも ear ファイルにデプロイされていることを意味します。私はマルチモジュールのmavenとearプロジェクトに少し慣れていません。

Web モジュールがあり、ear モジュールが Web モジュールを参照しています。私の耳では、pom Iv は Web モジュールを (not ) の下の依存関係として言及しました。現在、作業中のプロジェクトでは、すべての jar が「Ear Libraries」と呼ばれるライブラリ内の ear から web モジュールに送られています。これらの jar は、作業中のプロジェクトの web-module の「Java EE モジュールの依存関係」で確認できます。

しかし、作成したプロジェクトの Web モジュールに jar が表示されないため、すべての外部クラス (smartgwt クラスなど) に対してエラーがスローされます。POM も同様です。プロジェクトを別のワークスペースにインポートしましたが、現在は使用しています。プロジェクトが破損しましたか？最初から始めましょうか。

編集

POMのせいではありません。両方のアプリケーションで同じ POM を使用しています (コピーして貼り付け、アプリケーションの名前を変更するだけです)。それらは同じ構造、同じモジュールを持っています。M2Eclipse 0.9.9 と RAD 7.5 を使用しています

作業中のプロジェクト web-module pic

動作しない

EAR ライブラリの下で、jar が Working プロジェクトに反映されていますが、Error-Project には反映されていません。

私はかなり大きなマルチモジュールのmavenプロジェクトに直面しています。ルート (親) プロジェクトがサブプロジェクト/子プロジェクトから groupId:artifactId の形式でどのように構成されているかを確認したいと思います (階層を反映するための識別が可能です。

もちろん、このプリントアウトを取得するために独自のプラグインを作成することもできますが、シェルフから利用できるものがあるに違いないと考えています。

優れたスケーラブルなソリューションが見つからない問題：

特定のアーティファクトの複数のフレーバーを提供するプロジェクトがあります。これはマルチモジュールプロジェクトとして設定されており、現在3つのモジュールがあります。

• / flavour1_module
• / flavour2_module
• / flavour3_module

問題は、同じ方法でセットアップする必要がある別の50のプロジェクトがあるということです。つまり、3つのフレーバーを提供します。

検討したソリューション：

1. すでに作成されたマルチモジュールプロジェクトを他のすべての50プロジェクトの親に変える
   • 短所：それはうまくいきません。親のモジュールで保持されている命令は継承されないため、実行されません。
2. maven-archetype-pluginを使用してマルチモジュールプロジェクトテンプレートを作成し、テンプレートに基づいて50個すべてのプロジェクトを作成します
   • 短所： flavour4が必要な場合は、50個のプロジェクトすべてを手動で更新してflavour4_moduleを追加する（そしてそのコンテンツを複製する）必要があります。スケーラブルではありません。
3. すべてのフレーバーの構成を単一のpomに埋め込み、プロファイルに基づいてそれらを有効または無効にします（つまり、モジュールを介した継承ではなく、プロファイルによる構成を使用します）。次に、50のプロジェクトを親としてそのプロジェクトに向けます。これにより、「インライン」モジュールが作成されます
   • 短所：モジュールによって提供される独自のメカニズムをそのまま実装する必要があります。（たとえば、すべてのフレーバーを個別のディレクトリに構築します）。また、モジュールが提供する明確な分離も失われます。

それをうまく行う方法はありますか？他に選択肢はありますか？

ありがとう、Lukasz

編集：

もう1つのオプションは、maven-reactor-pluginをreactor：inject-modulesゴールで拡張することです。これにより、外部アーティファクトからモジュール定義がダウンロードされ、その定義が通常のモジュールとしてアタッチされます。これにより、その場で新しいモジュールが作成されます。次に、50のプロジェクトすべてがこのpom.xmlを親にすることができます。

構成は次のようになります（ドラフト）：

このように行くのは理にかなっていますか？

アップデート：

実行するモジュールのリストを操作するプラグイン（上記で説明したモジュールインジェクションのアイデア）を作成することは、モジュールがMavenコアによって処理され、メカニズムが拡張されるように設計されていないため、実装できないようです。プラグイン。これは、同様の仕事をする両方のプラグイン、つまり実行するプロジェクトのリストを操作するという事実によって確認されます。

• maven-reactor-plugin
• maven-invoker-plugin

システムコールを実行してMaven子プロセスを作成することでトリックを実行します。それは非常に不安定な解決策であるため、私にとってはそれは進むべき道ではありません。実際、maven-reactor-pluginはMaven3と互換性がなくなりました。

maven-invoker-pluginはまだ有望に見えます。プラグインは元々統合テストを実行するように設計されていましたが、コンパイルフェーズなどを拡張するために使用することも可能です。ただし、子pom.xml-sをリソースとして扱い、その場で変更する必要があります。ここで説明した問題の場合、解決策は複雑すぎて不安定になります。Mavenモデルを構築している間、メモリ内で動作できるより軽いものが好きです。

そのため、今のところ、プロファイルを使用して、可能な限りコンパクトにしようとしています。おそらくしばらくすると、問題についてもう一度考える必要があります。

Eclipseの下で同じマルチモジュールMavenプロジェクトの2つの異なるバージョンで作業したいと思います。

残念ながら、EclipseでマルチモジュールMavenプロジェクトをインポートする場合、競合を防ぐために親モジュールプロジェクト名を自分で変更できますが、子モジュールプロジェクト名は変更できません。子モジュールは、モジュール名にちなんで名付けられたルートプロジェクトとしてインポートされます。どうやら、インポート中にそれらの名前を変更する方法はありません。

理想的なシナリオでは、pomをそのままにしておきたいです。明らかに、私は同じEclipseワークスペースを維持したいと思います...

この投稿の長さについてお詫び申し上げますが、写真を提示せずに簡潔にするのに苦労しました。私は最近、Maven3.0マルチモジュールプロジェクトのビルドマスターの仕事を引き継ぎました。問題は、プロジェクト/モジュールの構造が災害であるということです。現在ソース管理（RTCを使用）に保存されている方法からモジュールのpom構造まで、毎回完全なビルドサイクルを完了させようとして、髪の毛を引き裂いています。

プロジェクト階層が進むにつれて、すべてのモジュールは「フラット」に保存されます。つまり、すべてが同じレベルにあります。私は親pomを持っており、すべてのモジュールは親に依存しています。ただし、親は他のすべてのモジュールと同じレベルにあります。

元：

親pomは、プロジェクトのビルドに必要なすべてのモジュールと、さまざまなサブモジュール全体で使用されるアーティファクトのバージョン番号の一連のプロパティを定義します。

次に、各モジュールのpomは、pomのアーティファクト番号を介して親pomに依存します。

さらに混乱させるために、実際のアーティファクト名は（モジュールに応じて）モジュールパスと一致する場合と一致しない場合があります。たとえば、module1はパスに配置されc:\dev\MyEarProject\module1ていても、アーティファクト名はhibernate-moduleです。ただし、RTCでの保存方法により、module1チェックアウト時にディレクトリが呼び出されます。

もちろん、すべてを構築する最も簡単な方法は、にアクセスしc:\dev\MyEarProject\parent-pom\て実行することmvn clean deployです。SNAPSHOTリポジトリでは同じアーティファクトバージョンの複数の展開が可能であるため、これはSNAPSHOTモードで正常に機能します。しかし、リリースモードでは、これは失敗します。

この構造は私にとって2つの問題を引き起こしています。

1. 親のプロパティにバージョンを変更する必要があるたびに、親-pomのバージョン番号、すべての子モジュールの親pomのバージョン、およびすべての子モジュールのバージョン自体を更新する必要があります（親が変更されたため）。
2. リリースサイクルをデプロイする必要があるときはいつでも、モジュールの1つが最後のサイクル以降変更されておらず、その結果、同じリポジトリに再デプロイできない場合、mvnはエラーをスローします（リポジトリは既存のアーティファクトの上書きを許可しません）

したがって、これらの問題を回避するために、このプロジェクトを再構築するための最良の方法を探しています。親pomの場合、代わりに相対パスを使用して親を指すことができます。ただし、モジュールの「フラットな」構造を考えると、これは推奨されるアプローチですか（つまり、親pomの相対パスは../parent-pom/pom.xmlになります-私には少し奇妙に思えます）？さらに、親のバージョン管理がモジュールから独立していることを考えると、相対パスを使用するだけでなく、追加の混乱への扉が開かれます（つまり、親pomのどのバージョンがどのバージョンに関連付けられているかを知る方法はありませんサブモジュールの）。

次に、発生しているデプロイエラーに遭遇することなく、耳全体を構築するにはどうすればよいですか？アーティファクトはすでにリポジトリに存在するため、再構築して再デプロイする必要はありません。--projectsを使ってみましたが、モジュールの数が多いため、管理が非常に難しくなります。