問題タブ [maven-reactor]

1日に2回質問するのはマウベイトンだと知っていますが、もう1つのMavenパズルゲームがあります。

5つのモジュール（5つのサブプロジェクト）を定義する親POMがあります。各モジュールはまったく同じ方法で実行されるため、<profile><build>セクションを親POMにプルして、重複するコードを取り除きます。さて、各モジュールから個別にビルドを実行すると機能しますが、すべてのモジュールを一度にビルドして親ディレクトリに移動すると、Mavenが最初に実行しようとするのは親プロジェクト自体であるため、エラーが発生します。

その後、execプラグインがそこにないものを実行しようとするため、ビルドは失敗します。出力を見ると、reactorプラグインがビルドを駆動していることは明らかですが、親をスキップするようにreactorを構成するにはどうすればよいですか？

samePS混乱を防ぐために-ビルド中に親でのプロファイルの実行を抑制し、子で有効にしようとしています

私は Maven リアクターについて読んでいますが、その用語の使用法に混乱しています。マルチモジュールはリアクターであり、Mavenリアクターを操作でき、リアクターはプラグインであることを読みました。原子炉とは正確には何ですか？

私はMavenマルチモジュールプロジェクトに取り組んでいます。特定のモジュールをビルドし、ユニットテストをスキップしてビルドプロセスをスピードアップしたいと思います。

私は次のことを試しました：

mvn reactor:make -Dmake.folders=search -Dgoals=package,-DskipTests

mvn reactor:make -Dmake.folders=search -Dgoals=package -Dmaven.test.skip=True

ただし、これによる影響はありません。手がかりはありますか？

3 つのモジュール (ModuleA、ModuleB、ModuleC) があります。ModuleC を独立した jar (db スクリプトを含む) として抽出しました。

pom.xml では、以下のようなことをしようとしています。

その JAR モジュール (ModuleC) をリアクター内に含めて、通常のモジュールと同じようにビルドするにはどうすればよいですか。依存関係として追加すると、その中のスクリプトはプロファイル呼び出し中にどのように実行されるでしょうか?

上記に加えて、以下に示すようなプロファイルもあります。

プロファイルが呼び出されたときに実行されるように、このプロファイルに ModuleC (JAR) を追加する必要があります。

アイデアはありますか？

親といくつかのモジュールを含むマルチモジュールプロジェクトがpom.xmlあり、一部のモジュールは相互に依存しています。プロジェクトディレクトリで私は呼び出すことができます

各モジュールでユニットテストを実行します。ここでは問題ありません。しかし、私が電話すると

モジュールレポートの1つ

これらの依存関係は「mvntest」中に検出されるため、これは発生しないはずです。また、それらはアーティファクトサーバーではなく、親プロジェクトの一部です。ERRORに記載されている目標は目標siteです。なぜmvn test成功し（検出した依存関係に関して）成功mvn siteしないのですか？これは原子炉のビルドであるため、特別な方法でサイトをビルドする必要がありますか？

私はこれをかなり長い間検索してきましたが、必要な答えが見つかりませんでした。

私は3つのモジュールで構成されるプロジェクトに取り組んでいます:

1. モジュール (jar)
2. サーバー (戦争)
3. クライアント（戦争）

サーバーとクライアントはモジュールに依存しますが、クライアントもサーバーがクライアントの前に構築されるという事実に依存するため、クライアントの wsimport がそれらをインポートしてクライアント クラスを生成する前に WSDL が生成されます。

クライアント プロジェクトがサーバー プロジェクトに依存するように設定するには、サーバー プロジェクトが含まれたりオーバーレイされたりせず、クライアントの前にclient.warMavenbuildとサーバーにのみ指示するようにするにはどうすればよいですか?package

war-deployまた、サーバー プロジェクトのパッケージ段階で Glassfish アクションに追加する方法は?

現在、サーバーとクライアントに埋め込むことができるモジュールプロジェクトのみに依存するクリーンなプロジェクトしかありません。

Jenkins、Maven、Tycho に少し奇妙な問題があり、誰が犯人かを突き止めるのは難しいです。

SCM でトリガーされたビルドはすべて失敗しますが、手動でトリガーされたビルドはすべて成功します。

ジェンキンス版：ジェンキンス版。1.527
Maven バージョン: 3.05

モジュール化された tycho ビルドがあります。

Jenkins は、モジュールを使用した単純な Maven ビルドとして構成されます。

実行するだけです：

SCM ビルドがトリガーされると、一部のモジュールがビルドされません。

手動でビルドすると、すべて問題ありません。

この動作は一貫しています。私はすでに試しました

• 別の Maven バージョン (3.05 / 3.04) への切り替え
• ビルド前にワークスペース全体を削除する
• すべてのソースのクリーン チェックアウト
• 実行中-X deploy（クリーンなし）

手動呼び出しは、何度でも成功します。そして、scm トリガーはいくらでも失敗します。

両方の Maven ログは、(動作するまで) まったく同じように見えます。

そして（失敗）：

したがって、最終的なエラー メッセージは次のようになります。

顧客固有のモジュール名は ------------ に置き換えられます。この質問で。

完全な原子炉プロジェクトを構築する際に、インストールするモジュールを選択的に指定する方法はありますか?

本質的には、完全なリアクター コンテンツをパッケージ化したいのですが、インストールするのはごく一部です。

モジュールの除外を Jenkins maven プラグインで動作させることができません。以下の出力を参照してください。

コマンドを同じジョブのビルド前のシェル ステップにコピーすると機能します。

スタック トレースでは、hudson-maven エージェントが干渉していることがわかります。主な違いは次のとおりです。

• ハドソンの使用org.codehaus.plexus.classworlds.launcher.Launcher.launchStandardとシェルの使用...launchEnhanced
• hudson は失敗するorg.apache.maven.DefaultMaven.trimSelectedProjectsが shell は失敗する...trimExcludedProjects

完全なスタック トレースは次のとおりです。

ビルド前のステップで存在しないモジュールを意図的に除外しようとしたときの失敗スタック トレースと比較してください。

私も-pl !gotham/java/dev-server構文を使用してみましたが、同様の後にスペースを入れないplようにしました-pl!gotham/java/dev-server

注:これらの実行には小さな違いがあります。シェルから直接実行されUsing local repository at /home/jenkins/.m2/repositoryたものはそうですが、プラグインを介して実行されたものはそうではありません。何が原因かはわかりませんが、関連しているとは思えません

maven-project プラグイン v. 2.8 (最新) で Jenkins バージョン 1.540 を使用しています。

子モジュールが個別にバージョン管理されるリアクター pom があります。子モジュールは、メイン pom のバージョンから独立した独自のバージョンを宣言します。ただし、2 つの子モジュール間には依存関係があります。リアクター pom の実際のモジュールによって宣言されているバージョンを常に使用するように、この依存関係をどのように構成する必要がありますか?

ルート pom で依存関係管理を設定し、いくつかの暗黙的なプロパティを使用して子モジュールのバージョンを決定できると期待していますが、私が見つけることができる最良のオプションは次のとおりです。

または単に

ルート pom の依存関係管理は次のようになります。

新しいモジュールまたは依存関係が追加されるとリアクターの順序が変わる可能性があるため、信頼性がないように見えます。

たぶん、この使用シナリオは設計上推奨されていないので、その理由を知りたいです。

編集:コメントで示唆されているように、親 POM で子バージョンを持つグローバル プロパティを宣言することは、Maven の新しいバージョンのオプションになる場合があります。ただし、ワークフロー、リリース、ディレクトリとリポジトリの設定、一部のプラグインの使用法 (バージョン プラグインなど) など、より幅広い結果に関する分析を見たいと思います。たとえば、このアプローチの直接的な結果は、リリースする必要があることだと思います。子モジュールのいずれかがリリースされるたびに、親モジュール。これは実行可能ですが、独立したバージョン管理を行うという当初のアイデアに影響を与える可能性があります。