問題タブ [maven-release-plugin]

私は何かが足りないと思います..
私のプロジェクトをリリースしたいと思います。
pom に maven-release-plugin を追加しました。さらに、java 以外に別のソース コード dir があります (gen-src と呼びます)。Maven リリースで最初のステップを実行する (つまり、準備する) ときはすべて問題ありませんが、実行するときは gen-src が考慮されません。

位相が発生源であることと関係があるのではないかと思います。add-source ゴールを別のフェーズにアタッチする必要がありますか? はいの場合、どのように？私もここで
読みました-これは同様の問題ですが、フレックスを使用していません..答えはありません。何か案が？ありがとう。

Maven と NPanday を使用する C# .NET Web サービス プロジェクトに取り組んでいます。リリース プラグインも使用したいのですが、マイナーなバージョン管理の問題が見つかりました。

NPanday はAssemblyInfo.cs、ビルド時に POM ファイルのバージョン番号でファイルを (便利に) 更新しますが、その変更を SVN にコミットしません (また、必ずしもそうしたいとは思いません)。

リリース プラグインはそのことを認識していませんAssemblyInfo.cs(また、私が期待することもありません)。しかし、これは、私の AssemblyInfo.cs と POM のバージョンが、リリース操作中に同期されなくなることを意味します。

たとえば、mvn release:branchトランクから 2.0.x ブランチを作成するとします。POM とAssemblyInfo.csおそらく両方とも、分岐前のトランクで 2.0.0-SNAPSHOT にあったため、分岐は期待どおりに見えます。しかし、更新されたトランクでは、POM バージョンが更新されています (例: 2.1.0-SNAPSHOT) が、AssemblyInfo.cs はまだ 2.0.0-SNAPSHOT のままです。

mvn compileトランクの次のものが更新され、AssemblyInfo.cs誰かがそれをコミットするため、これは大きな問題ではありません。しかしrelease:prepare、ブランチから作成されたタグの POM には正しいバージョン (2.0.0 など) が含まれているため、さらに悪化しますが、AssemblyInfo.csそれでも -SNAPSHOT と表示されます。release:perform が実行されると、NPanday はAssemblyInfo.csファイルを更新しますが、そのタグからのフローティング変更があります。

リリースプラグインでこれを修正する方法を知っている人はいますか? 確かに、手動で正しいブランチ/タグを作成したり、カスタム ツールをコーディングしたりできました。または、「AssemblyInfo.cs ファイルは決定的なバージョン ソースではなく、POM です」と言ってそのままにしておくこともできます。しかし、私は両方の長所を好む.

私のチームには、いくつかのレポート プラグイン構成を含むモジュールを持つ共通の親プロジェクトがあります (たとえば、checkstyleのマルチモジュール構成に似ていますが、別のプロジェクトにある checkstyle と findbugs)。共通の親プロジェクトを「common」、レポート モジュールを「build-tools」と呼びます。

共通プロジェクトがリリースされたときに、手動リリースを行わずに共通プロジェクトが正しいバージョンの build-tools モジュールを参照するようにする方法を見つけようとしています。

ここに私が試したことのいくつかがあります：

• build-tools のバージョン番号には ${project.version} を使用します。これは、共通を親として使用するプロジェクトで指定されたバージョン番号を使用します。
• 通常のバージョン番号を使用してください。これらは共通プロジェクトでは更新されません。
• プロパティを使用します。繰り返しますが、プロパティ値はリリース時に更新されません。

ありがとう！

Maven 2、Bamboo 3.1、およびJIRA4.3を使用してリリースを管理するための最良の方法を見つけたいと思います。私は多くのことを試しましたが、バグや機能の欠如のために行き止まりになり続けています。

私の最終目標は、バージョンをJIRAから取得し、Bambooにそれらのバージョンを取得させ、Mavenを使用してそれらからアーティファクトを構築し、それらのアーティファクトをリポジトリー（この場合はNexus）にデプロイすることです。

これが私が試したアプローチです：

1）プロジェクトバージョンのすべてのpomでプレースホルダーを使用します。

親pom

子ポン

これは、プロジェクトのルートpomからビルドを開始-Dci.version=<my-version>し、コマンドラインで指定した場合にビルドされます。これをBambooリリース管理プラグインと組み合わせると、モジュールのバージョンをビルドしてデプロイし、必要に応じてリリースできます。

このアプローチの問題は、Mavenがデプロイまたはインストール時にpomsのプレースホルダー変数を置き換えないことです。つまり、リポジトリ内のpomに${ci.version}は、具体的なバージョンが本当に必要なときにマーカーがあります。プレースホルダーがあるため、私が展開したモジュールを誰も使用できないことを意味します。MNG-2971を参照してください。

2）pomで具体的なSNAPSHOTバージョンを使用し、Bambooリリース管理プラグインを使用してMavenリリースプラグインを実行するようにbambooを構成します。

残念ながら、Mavenリリースプラグインではバージョンをインクリメントする必要があります。bambooプラグインでは、ビルドする現在のバージョンの名前を取得できますが、次のバージョンの名前を取得することはできません。この情報がないと、Mavenリリースプラグインを使用して、バージョンをJIRAによって管理されていないものにインクリメントします。このオプションを機能させるには、次のバージョンを利用できるようにするか、Bambooリリース管理プラグインがそれを実行した後にプランを実行できるようにする必要があります（この2番目の修正では、コミットログに余分な混乱が追加されます自動増分用に1つのコミットを取得し、適切な増分用に1つのコミットを取得します）。

2.b）2）と同じですが、プラン構成インターフェースを介してリリースをビルドする前に、Bambooで次のバージョンを指定する必要があります。値を手動で、プランが機能する次のJIRAバージョンに設定します。これにより、2）の問題が修正されますが、手動の手順が追加されます。

3）おそらくMavenリリースプラグインを使用して、手動で処理を実行します。Bambooのすべてのリリース機能を完全に無視し、Mavenリリースプラグインの目標を呼び出して必要に応じてバージョンを変更することにより、コマンドラインでリリースを手動で管理します。これが発生した場合は、JIRAバージョンも手動でリリースする必要があります。また、リリースプラグインが非SNAPSHOTバージョン用に作成するタグを実行およびテストするようにbambooビルドを構成する必要があります。

このオプションには非常に多くのプロセスが含まれており、何かがうまくいかない可能性があります。

これらのテクノロジーを使用して自動リリースを取得しようとしているのは私だけではありません。誰でも助けてくれます。

ありがとう

Maven 3.x を使用して web アプリケーションを tomcat にデプロイしようとしています。これは pom.xml ファイルのスナップショットです。

Mavenで次の目標を試しましたmvn deployが、次のエラーで次のビルドが失敗しました

いくつかのグーグルを行った後、次のエントリを pom.xml に追加しました

${user.home}/m2/repositoryしかし、使用するとビルドの失敗で別のエラーが発生したため、URLがどうあるべきかわかりません

問題を解決するには？

Jboss や Tomcat などの構造を持つ Java アプリケーションを構築するにはどうすればよいですか?

デフォルトの Maven Project -> Simple Project があります。

構築後に構造の下に置きたい：

bin : jar をシェルで実行できるように、すべてのシェル ファイル。
lib : My Java Classes を含むすべての JAR が含まれています
。Jboss や Tomcat と同様です。

Maven 、または Maven Plugin を使用するにはどうすればよいですか?

\branches\branchone にあるブランチから Maven リリース プラグインを実行すると、\branches のタグが作成されます

プラグインで「branchone」だけをタグ付けしたいのですが、何らかの理由で代わりに「branches」全体をタグ付けします。

これはバグのようです。プラグインは、現在の scm の「接続」URL を使用して、何をタグ付けするかを決定する必要があります。

リリース プラグインが正しいディレクトリにタグ付けしない理由を知っていますか? または回避策を知っていますか?

私は現在、Jenkins (1.430) でプロジェクトのリリース プロセスを強化しています。

現在のリリース ジョブ

現在、ある特定のプロジェクトについて、リリース プロセス専用のジョブが 1 つあります。完全な手順は次のとおりです。

1. リリースを担当する開発者は、すべての pom.xml ファイルのバージョンを (実際には を使用してmvn versions:set -DnewVersion=2.0) 手動で変更し、-SNAPSHOT.
2. 次に、SVN でタグを作成します (例: http://my-svn-repo/project/tags/V_2_0 )。
3. このタグが作成されると、Jenkins サーバーにログオンし、リリース ビルドを開始します。
4. このビルドでは、ビルドに使用するタグを尋ねます。ジョブは、パラメーターList Subversion tagsを使用して、パラメーター化されたビルドとして構成されます。
5. Jenkins はこのタグからアーティファクトを構築し、Nexus インスタンスにデプロイします。
6. これが完了すると、開発者は pom.xml バージョンを新しい開発バージョン (つまり2.1-SNAPSHOT) に設定します。

この方法の利点は、ビルドがタグのみに依存するため、Jenkins ジョブしかないことです。

ただし、この手順には人間の介入が多すぎます (pom.xml、コミット、タグなどの変更)。

新しいリリース ジョブ

現在、Maven リリース プラグインを使用しています。ビルドを起動するユーザーに 3 つの情報を尋ねるジョブを作成しました。

• リリースのバージョン (releaseVersionリリース プラグインのパラメータ);
• リリース後の開発バージョン (developmentVersionリリース プラグインのパラメーター)。
• タグの名前 (tagリリース プラグインのパラメーター)。

このジョブは、1 つの点を除いて正常に機能します。ジョブは、トランクまたは SVN のブランチに基づいています。これは、(トランクに加えて) 2 つのブランチがある場合、3 つのリリース ジョブ (ブランチごとに 1 つ) を作成する必要があることを意味します。

2 つの世界 (つまり、mvn リリースを使用するが、1 つのリリース ジョブを維持する) の長所を維持するための 1 つのアイデアは、トランク/ブランチのパスをユーザーに尋ねるビルド パラメーターを追加することです。そのため、ジョブ構成でhttp://my-svn-repo/project/trunk(または)を設定する代わりに、 を設定し、ユーザーにパラメーターの入力を求めます。http://my-svn-repo/project/branches/BRANCH_V1http://my-svn-repo/project/$FROM_BRANCHFROM_BRANCH

このソリューションの問題は、ユーザーが または のいずれtrunkかを入力する必要branches/BRANCH_Vxがあり、エラーが発生する可能性があることです。

理想的には、パラメータList Subversion tagsがタグの選択のために存在するため、ブランチ (トランクを含む) の選択を可能にするビルド パラメータが欲しいです...

私の質問:すべてのブランチで機能する1 つのJenkins ジョブを構成するより良い方法はありますか?

ありがとう。

編集: Validating String Jenkins プラグインが見つかりました。これは、ユーザーが定義した値が正規表現を尊重することを保証するのに興味深いものです。それは私の場合に役立ちます...

非常によく似たプロジェクトがいくつかあります。Git ブランチから mvn リリースを行おうとしています。(ブランチをチェックアウトしてから、mvn release を実行します)。一部のプロジェクトではこれで問題なく動作し、他のプロジェクトでは mvn release:prepare は問題なく動作しますが、mvn release:perform を実行すると失敗します。

「cd ...target/checkout && git pull ...」を実行しようとすると失敗します。次のようになります。

コマンドを手動で実行すると、pom.xml で git マージの問題が発生します。私の推測では、マスターとブランチで pom.xml のバージョンが異なると失敗します。つまり、1.4 ブランチのバージョンが 1.4.2-SNAPSHOT で、トランクのバージョンが 1.5.0-SNAPSHOT の場合、失敗します。

私の考えでは、pom が同一である必要はありません。マスターからではなく、git ブランチから mvn:release を実行しています。それはそれほどひどく奇妙ではありませんね。誰もこれについて知っていますか？

We're using a standard svn layout (/branches/x.y, /tags, /trunk) and mvn release (i.e. maven-release-plugin) to perform releases, from the branches.

We usually try to make sure the section follows the branch, so it looks like this

Can anybody tell me whether the "branches/1.5" at the end is strictly necessary? Or does maven-plugin figure this out anyway? What happens if it's wrong - say I'm on the 1.5 branch and the scm section of the pom say 1.4, or trunk? I have no immediate desire to try it. :-/