Mavenプロジェクトバージョンの継承-親バージョンを指定する必要がありますか?


189

2つのプロジェクトがあります。親プロジェクト:A、サブプロジェクト:B

A / pom.xml:

<groupId>com.dummy.bla</groupId>
<artifactId>parent</artifactId>
<version>0.1-SNAPSHOT</version>
<packaging>pom</packaging>

そしてB / pom.xmlには、

    <parent>
        <groupId>com.dummy.bla</groupId>
        <artifactId>parent</artifactId>
        <version>0.1-SNAPSHOT</version>     
    </parent>

    <groupId>com.dummy.bla.sub</groupId>
    <artifactId>kid</artifactId>

Bに親からバージョンを継承させたいので、私の場合、置く必要があるのはだけ0.1-SNAPSHOTですA/pom.xml。しかし、親セクションの下<version>0.1-SNAPSHOT</version>からを削除するとB/pom.xml、Mavenは親のバージョンがないことについて不平を言います。

両方のポンポン${project.version}を避けるために私がちょうど使用できる方法またはこのようなものはあり01.-SNAPSHOTますか?


4
そのためには、Maven 3.1を待つ必要があります。
認識



1
上記のリンクは移動しました。最終的なステータスは「クローズ/修正されない」issues.apache.org/jira/browse/MNG-624
jocull

回答:


86

編集: Maven 3.5.0以降、${revision}プレースホルダーを使用してこれを解決する優れた方法があります。詳細については、FrVaBeの回答を参照してください。以前のMavenバージョンについては、以下の私の元の回答を参照してください。


いいえ、ありません。常に親のバージョンを指定する必要があります。幸い、ほとんどの場合に望ましいモジュールのバージョンとして継承されます。さらに、この親のバージョン宣言はMavenリリースプラグインによって自動的にバンプされるため、Mavenリリースプラグインを使用してバージョンをリリースまたはバンプする限り、実際にバージョンが2か所あることは問題ではありません。

この動作が実際にはかなり問題なく、必要に応じてより柔軟になる場合があることに注意してください。以前の親のバージョンの一部を使用して継承したい場合もありますが、それは主流のケースではありません。


3
${revision}これで、プレースホルダを使用できるようになりました。私の答えを見てください;-)
FrVaBe '22

2
これは古くなっています-@FrVaBeの答えをここで確認してください:stackoverflow.com/a/51969067/514483
robd

@FrVaBe異なるバージョンのネストされた親がある場合はどうなりますか?そこでは1つの$ {revision}プロパティを使用できません。それだけでは不十分です。
ハリル

@halil問題は、2つのアーティファクトで同じバージョンを持つことを目的として、親からバージョンを継承することです。(継承階層に)異なるバージョンの異なる親がある場合、それらをすべて同じバージョンにすることはおそらくないでしょう。したがって、コメントを完全には理解していません。
FrVaBe

86

Mavenはそのように動作するように設計されていませんが、この目標を達成するための回避策が存在します(おそらく副作用があり、試してみる必要があります)。トリックは、純粋なmaven座標ではなく相対パスを介して親を見つけるように子プロジェクトに指示し、さらにプロパティのバージョン番号を外部化することです。

親ポン

<groupId>com.dummy.bla</groupId>
<artifactId>parent</artifactId>
<version>${global.version}</version>
<packaging>pom</packaging>

<properties>
   <!-- Unique entry point for version number management --> 
   <global.version>0.1-SNAPSHOT</global.version>
</properties>

こどもポン

<parent>
   <groupId>com.dummy.bla</groupId>
   <artifactId>parent</artifactId>
   <version>${global.version}</version>
   <relativePath>..</relativePath>    
</parent>

<groupId>com.dummy.bla.sub</groupId>
<artifactId>kid</artifactId>

私のプロジェクトの1つでこのトリックをしばらく使用しましたが、Mavenがビルドの開始時に多くの警告をログに記録するという点を除いて、特に問題はありませんでした。

編集

maven 3.0.4では、このような設定はできなくなりました。


2
そうです、mavenはそのように機能するようには設計されていないと思います。バージョンをサブpom.xmlに置くことをお勧めします。Mavenリリースプラグインは、とにかくそこにあるバージョンを本当に気にしません。
盛傑

7
3.0.5は問題なく動作します。ただし、<properties>を最上部に配置する必要があります。
2013

7
3.2.3で動作します。<properties>の場所は関係ありません。:あなたは警告けれども買ってあげる'version' contains an expression but should be a constant.
kapex

4
これに注意してください。これは、プロジェクトが別のプロジェクトによって参照されている場合は機能しません。プロパティは解決されず、文字どおりに処理されます(つまり、$ {my.version})。これにより、依存関係を解決するときにエラーが発生します。
spekdrum 2016

2
私もこれをかなり長い間使用してきましたが、単一のマルチモジュールプロジェクトで(現在はMaven 3.3.9で)正常に動作します。ただし、プロジェクトが別のプロジェクトの依存関係になるとすぐに、事態は非常にトリッキーになります。以下の@payによって提案された提案を採用することを本当にお勧めします。
独創的な

81

IMOのバージョンを更新する最も簡単な方法:

$ mvn versions:set -DgenerateBackupPoms=false

(ルート/親pomフォルダーでそれを行います)。

POMが解析され、どのバージョンを設定するか尋ねられます。


17
-DnewVersion = {versionToBeUpdated}を追加して、インタラクティブに入力しないようにすることもできます。
Mukesh 2016年

1
私はこれが最良の答えだと思います。サブプロジェクト(親pomなしでは参照できない)を壊すことなくバージョン変更を自動化します。
Tarek、2018

うん!これが答えです。🙌
aaiezza

子と親のpomバージョンが最初に異なる場合は、最初にそれらを一致するように更新し mvn versions:update-child-modules ます。それ以外の場合、すべての子モジュールのpomバージョンはスキップされます。
Gautam Tadigoppula

75

Maven 3.5.0以降では${revision}、そのためのプレースホルダーを使用できます。使い方はここに文書化されています:Maven CI Friendly Versions

つまり、親pomは次のようになります(Apacheのドキュメントから引用)。

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
  <properties>
    <revision>1.0.0-SNAPSHOT</revision>
  </properties>
  <modules>
    <module>child1</module>
    ..
  </modules>
</project>

そしてこのような子ポンポン

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache.maven.ci</groupId>
    <artifactId>ci-parent</artifactId>
    <version>${revision}</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-child</artifactId>
   ...
</project>

また、Flatten Mavenプラグイン使用して、デプロイメントに含まれる専用のバージョン番号を含むpomドキュメントを生成する必要があります。HowToはリンクされたドキュメントに記載されています。

また、@ khmarbaiseがこの機能について素晴らしいblob投稿を書きました:Maven:バージョンのないPOMファイル?


説明したようにプロジェクトを構成しましたが、「Flatten Mavenプラグイン」がなく、期待どおりに動作しているようですが、これは可能ですか?また、maven 3.2.1でエラーが発生しましたが、maven 3.3.9以降は正常に動作するようです。
最大

@Maxそれはあなたが「期待通りに働く」とあなたが定義するものに依存します。ビルドは成功すると思いますが、リポジトリへのインストール/デプロイは、子pomにバージョン番号がなく、プレースホルダー(ドキュメントを参照)しかないため、おそらく良いアイデアではないでしょう
FrVaBe

親pomでデフォルトのプロパティ(<properties> <version> 0.1-default </ version> </ properties>を使用して<version> $ {revision} </ version>を使用しています。子pomも<version> $ {revision} <を使用しています/ version>。 "mvn clean install -Drevision = 0.1。$ {bamboo.buildNumber}"を使用します。展開のログをスキャンすると、すべてが0.1.820に設定され、0.1-defaultはログ(820はビルド番号です。結果のjarをスキャンすると、マニフェストに「Implementation-Version:0.1.820」が表示され、pom.propertiesファイルにも「version = 0.1.820」が表示されます。pomファイル自体には<version> $ {revision} </ version>。それでいいと思いますか?
Max

1
@Maxバージョンが${revision} pom(mavenリポジトリー内)にあるjar を別のプロジェクトの依存関係として解決しようとします。これがうまくいくとは思いません。
FrVaBe

これは私がリリースするときを除いて便利です。${revision}バージョンタグで新しいバージョンに置き換えられます
Mike D

21

Yanfleaが述べたように、これを回避する方法があります。

Maven 3.5.0では、次の方法で親プロジェクトからバージョンを転送できます。

親POM.xml

<project ...>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mydomain</groupId>
    <artifactId>myprojectparent</artifactId>
    <packaging>pom</packaging>
    <version>${myversion}</version>
    <name>MyProjectParent</name>

    <properties>
        <myversion>0.1-SNAPSHOT</myversion>
    </properties>

    <modules>
        <module>modulefolder</module>
    </modules>
    ...
</project>

モジュールPOM.xml

<project ...>
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>com.mydomain</groupId>
        <artifactId>myprojectmodule</artifactId>
        <version>${myversion}</version> <!-- This still needs to be set, but you can use properties from parent -->
    </parent>

    <groupId>se.car_o_liner</groupId>
    <artifactId>vinno</artifactId>
    <packaging>war</packaging>
    <name>Vinno</name>
    <!-- Note that there's no version specified; it's inherited from parent -->
    ...
</project>

myversion予約済みのプロパティではないものに自由に変更できます。


3
別のプロジェクトからモジュールを参照する場合、Mavenはプロパティを解決しません。それは正常ですか?
LeoLozes 2018

私はその質問はそれ自身のエントリーに値するかもしれず、このようなコメントには含まれないかもしれないと信じています。あなたのコードを見ずに、私は乱暴に推測することができるだけです。
eFox 2018

@LeoLozes問題を解決しましたか(別のプロジェクトの参照モジュール)?
Morteza Malvandi

@MortezaMalvandiはい!私の答えは一番下にあります:)
LeoLozes

2
Maven 3.6.0はこの構成に対して警告を出します:「ビルドの安定性を脅かすため、これらの問題を修正することを強くお勧めします。」「このため、Mavenの将来のバージョンでは、このような不正なプロジェクトのビルドをサポートしなくなる可能性があります。」
d2k2

18

あなたも使うことができます:

$ mvn release:update-versions -DdevelopmentVersion={version}

POMのバージョン番号を更新します。


10

eFoxの回答は単一のプロジェクトで機能しましたが、別のプロジェクトからモジュールを参照しているときは機能しませんでした(pom.xmlは.m2、バージョンではなく、プロパティを使用して引き続き私の中に保存されていました)。

ただし、これをと組み合わせると機能しflatten-maven-pluginます。これは、プロパティではなく正しいバージョンのpomを生成するためです。

プラグイン定義で変更した唯一のオプションはoutputDirectoryです。これはデフォルトでは空ですがtarget、私の.gitignore設定で設定されているで使用することを好みます。

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>flatten-maven-plugin</artifactId>
   <version>1.0.1</version>
   <configuration>
      <updatePomFile>true</updatePomFile>
      <outputDirectory>target</outputDirectory>
   </configuration>
   <executions>
      <execution>
         <id>flatten</id>
         <phase>process-resources</phase>
         <goals>
            <goal>flatten</goal>
         </goals>
      </execution>
   </executions>
</plugin>

プラグイン構成は親pom.xmlにあります



0
<parent>
    <groupId>com.dummy.bla</groupId>
    <artifactId>parent</artifactId>
    <version>0.1-SNAPSHOT</version>     
 </parent>

 <groupId>com.dummy.bla.sub</groupId>
 <artifactId>kid</artifactId>

Bのpomの親ブロックからバージョンを削除することを意味します。グループID、artifactId、およびバージョンが親のpom座標を指定しているため、実行できないと思います。省略できるのは、子のバージョンです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.