問題タブ [maven-release-plugin]

私たちは SVN/Maven/Hudson ショップです。非常に手間のかかるタグ付けとリリースのプロセスを自動化するために、Maven リリース プラグインの使用を実験しています。このプラグインに関してこれまで調査してきた結果に満足しています。

私たちの質問は、ビルド中のモジュール/アプリケーションの一部に異なるタグを付ける必要がある場合、応答をスクリプト化する方法はありますか?

インタラクティブな予行演習をうまく進めましたが、自動化をさらに進めるためにこれらをスクリプト化することを検討しています。

誰かがこれを試したことがありますか、それが可能かどうか知っていますか?

「バッチモード」はこの機能を許可しますか?

ありがとう

ジョー・R

Maven と Subversion の作業を行っています。

Maven プロジェクトを作成しました。ここで、リポジトリ (TortoiseSVN によって作成された) を指すようにします。ファイルを変更する必要があるMaven と Subversion のチュートリアルを読みました。pom.xmlこれらの指示に従って、次のようにscmタグを追加しました。

しかし、しようとするとmvn release:prepare、エラーが発生します。

何が起こっているのでしょうか？

私は最近 Maven プロジェクトをリリースしましたが、プロセス全体が非常に複雑でエラーが発生しやすいと考えずにはいられませんでした。3 つのモジュール A、B、C で構成されるアプリケーションがあり、それぞれが Subversion に独自のフォルダーを持ち、Hudson に個別のビルド ジョブがあるとします。各モジュールには、複数の成果物を集約する親 POM があります。A は B に依存し、B は C に依存します。依存関係のバージョンは、A、B、および C の親であるトップ レベルの POM D で定義されます。プロジェクト全体で使用される各アーティファクトのバージョンは 1 つだけです。リリースを行うために、次のことを行います。

1. Hudson を介してリリース プラグインを使用して、最上位の POM D をリリースします。
2. それ以上の依存関係がない C から始めます。
3. D のリリース バージョンを参照するように C を変更します。リリース プラグインを使用して C をリリースします。
4. C のリリース バージョンを D に入力して、C に依存するモジュールを C の安定バージョンでリリースできるようにします。
5. リリース プラグインを使用して D を再度リリースします。
6. B の場合は 3 ～ 5 を行います
7. A に対して 3 ～ 5 を行う

その後、A、B、C のすべてのアーティファクトの安定した非スナップショット ビルドを作成し、それらを組み合わせてアプリケーションの最終的な安定リリースを作成できます。

実際、私はそのようなモジュールを 3 つだけでなく 20 ほど持っていました。この手順は非常に複雑で、多くの潜在的な問題があると思います。

• 依存関係階層のレベルごとに 1 回ずつ、D を数回リリースする必要があります。最終的に、A、B、および C の安定バージョンのみを含む D ができました。次の開発バージョンに進むには、D を再度編集して、リリースされたモジュールのすべての新しいスナップショット バージョンを参照する必要があります。一般に、リリース プラグインを使用する場合でも、依存関係の管理はすべて手動で行う必要があります。

• 私がリリースしている間に誰かがコミットすると、物事が台無しになる可能性があります。確実にするには、すべてのモジュールで特定のリビジョンをチェックアウトし、ビルドしてテストし、そのリビジョンのすべてのモジュールをリリースする必要があります。しかし、ハドソンと複数のジョブでそれを保証するにはどうすればよいでしょうか?

• Subversion サーバー、Hudson サーバー、および Maven アーカイブ サーバーの 3 つの異なるシステムに依存します。1つだけダウンしていると、もうリリースできません。

• 時間がかかる。このプロセスでは、リリースするモジュールごとに、多くのビルド、パッケージ化、アップロード、ダウンロード、抽出などが何度も行われます。アーカイブとの多くの冗長なデータ交換が発生します。しかし、Hudson には必要なすべてのソース コードがあるため、実際にはすべてローカルで実行できます。最後に 1 回だけ、最終的なパッケージをアップロードする必要があります。

• アーカイブ サーバーでパッケージを紛失したとします。タグ付けされたバージョンをチェックアウトし、それらすべてを適切な順序で再構築するよう Hudson に指示する簡単な方法はありません。

すべてのコードを一度にチェックアウトし、1 つのグローバル バージョンを適用し、ビルドしてテストし、コミットし、コミットにタグを付け、最後にバイナリをアップロードするのと同じくらい簡単ではないのはなぜでしょうか?

これに関するアイデアをありがとう。

私の maven-metadata.xml には、Nexus の正しい RELEASE バージョンがありません。Nexus 1.8.0.1 を使用しています。maven-release-plugin を使用して Nexus にデプロイすると、ログにメタデータが更新されたことが示されます。また、正しいバージョンがバージョンのセットに追加されていることもわかります。<release>バージョンが間違っているだけです。

Nexus UI を使用してファイルを再作成しようとしましたが、うまくいきませんでした。

乾杯、

ジェフ

次のモジュールを含むマルチモジュール プロジェクトがあります。

• データベース
• 持続性
• 仕事
• 応用

「データベース」プロジェクトは、「maven-assembly-plugin」を使用して追加のアセンブリを作成する jar プロジェクトです。この追加のアセンブリには、データベース スキーマが含まれています。

プラグインの構成は次のとおりです。

「アプリケーション」プロジェクトは、アプリケーション ディレクトリ構造の圧縮バージョンを作成します。したがって、スキーマ アセンブリを参照して、それを抽出し、アプリケーション ディレクトリ構造内の適切な場所にコピーします。参照は、通常の maven 依存関係として表されます。

少なくとも、1 つのステップでアプリケーションをビルドするために 4 つのサブモジュールを集約するマルチ モジュール プロジェクトがあります。

集約プロジェクトで「mvn deploy」を実行すると、正常に機能します。データベース スキーマ アセンブリが抽出され、コピーされます。しかし、集約プロジェクトのビルドで「mvn release:prepare」を実行すると、「アプリケーション」プロジェクトが失敗し、maven がバージョン「0.0.1」のスキーマ アセンブリを見つけられないというエラー通知が表示されます。ログ ファイルには、'Persistence' プロジェクトが 'Application' プロジェクトの前にビルドされ、'database schema' アセンブリがビルドされたことが示されています。

誰が私が間違っているのか考えていますか?

リリースしようとすると、私はいつもこれを取得します:

「コマンド出力」では何もありません。

Maven を git とうまく連携させるための秘密の設定トリックはありますか?

Mavenプラグインを実装しようとしていますが、scmで問題が発生しました。プラグインはタグを削除する必要がありますが、それを行う方法が見つかりませんでした。このAPIの経験がある人はいますか？

これは、maven リリース プラグインを使用してリリースを行うときに発生する問題の抜粋です。リアクタープロジェクトに表示される basedir の大文字/小文字の c:\ と関係があると思いますが、修正方法がわかりません。私のMavenバージョンは次のとおりです。

これは、ビルドが失敗する部分です。

何かアイデアはありますか？

私はhudsonでmavenリリースプラグインを使用しており、autoVersionSubmodulesをtrueに設定して、pomsの開発バージョンを自動的にインクリメントしています。

プラグインにマイナーバージョンではなくメジャーバージョンをインクリメントさせる方法があるかどうか疑問に思っています。

現在、バージョン1.1.0-snapshotを使用している場合、次のバージョンは1.1.1-snapshotに設定されていますが、理想的には1.2.0-snapshotに変更したいと思います。

これを達成する方法について何かアイデアはありますか？

ありがとう。

私はMavenを初めて使用します。私は次のような製品構造を持っています

pom.xmlMavenリリースプラグインは、の親であるファイルの会社レベルで定義されますmyWebProduct。リリースプラグインの実行のデフォルトの目標deployとデフォルトのpreparationGoalsが設定されていますclean verify install。

myWebProductリリースをスキップしたい場合を除いて、正常に動作するレベルで製品をリリースしたいhtmlTestModule。deployライフサイクルをオンにすると、リモートのTomcatサーバーにwarファイルがデプロイされるためhtmlTestModule、リリース中にこれが発生することは望ましくありません。

のフォローインを追加してみましpom.xmlたhtmlTestModule。

ただし、で「mvnrelease：perform」を実行する場合myWebProduct。デプロイの目標がまだ実行されているのを見てきましたhtmlTestModule。誰かがこれを手伝ってもらえますか？

そして私もフォローしてみましたhtmlTestModule：

それでも、デプロイの目標は常にで実行されhtmlTestModuleます。ありがとう