Mavenリアクタービルドからモジュールを除外する方法は?


98

たくさんのモジュールが入ったMaven 2プロジェクトがあります。例:

<modules>
  <module>common</module>
  <module>foo</module>
  <module>data</module>
  <module>bar</module>
  ... more ...
</module>

「データ」モジュールはビルドに時間がかかり、プロジェクトがCIサーバーによってビルドされるときに除外するとします。現在、2つのpom.xmlファイルを使用してこれを実現しています。1つはその中にすべてのモジュールを持ち、もう1つはCIのために省略できるものを除いてすべてのモジュールを持っています。しかし、新しいモジュールを両方のファイルに入れるのを忘れることがあるので、それはかなり面倒です。

2つの個別のモジュールリストを必要としないソリューションはありますか?

回答:


73

次のように使用するのが最も簡単profilesです。

<project>
  ...
  <modules>
    <module>common</module>
    <module>foo</module>
    <module>bar</module>
  <modules>
  ...
  <profiles>
    <profile>
      <id>expensive-modules-to-build</id>
      <modules>
        <module>data</module>
      </modules>
    </profile>
  </profiles>
</project>

次に、プロファイルをアクティブ化する方法を確認する必要があります


Commonの前に発生するデータが必要な場合は、どうしますか?この場合、プロファイルモジュールは、リアクタの順序でデフォルトモジュールの後に配置されます。強制注文のパターンはありますか?
Peter Kahn、

9
モジュールの順番は、それらがリアクターに現れる順番ではありません。順序に影響を与える唯一の方法は、モジュール間の依存関係を作成すること、つまり<dependency>タグを使用することです。この宣言順序に依存することはできません。
SaM

7
@SaM実際には、Maven 3.0.5以降、Reactor は 'modules'の順序を考慮しますが、依存関係によって決まる順序の方が優先されます。
hellodanylo 2013

これにより、プロファイルが有効になっていても、プロファイル内のモジュールの検出に失敗する他の一部のプラグインが機能しなくなります
三倍体

143

Maven 3.2.1では、以下を使用できます -pl !<module_name>,!<module_name>して、reactorビルドから特定のモジュールを除外ました。

この機能リクエストを参照してください:https : //issues.apache.org/jira/browse/MNG-5230


3.0.4から3.2.1に切り替えても安全ですか、それとも大きな変更がありますか?
2014

3.1から3.2.1に問題なく移行しました。しかし、正直に言うと、それを理解するためにビルドを行う必要があります。
Yogesh_D 2014

30
シェルのコマンドラインで感嘆符をエスケープすることを忘れないでください。これは非常に特別な意味を持っています。たとえば、unix.stackexchange.com / questions / 3747 /…を
Pavel

5
残念ながら、現在、リアクターモジュールの除外をサポートしていないJenkins maven-projectプラグインに未解決の問題があります:issues.jenkins-ci.org/browse/JENKINS-26472
Nick Vanderhoven

@Pavel:またはの-代わりに使用する!、すなわち-pl -<module_name>
msa

45

ビルドするプロジェクトは、mvnコマンドラインでも指定できます。これにより、別のpomは不要になりますが、代わりに、新しいモジュールがあるたびにCI構成を変更する必要があります。

-pl,--projects <arg>                Comma-delimited list of specified
                                    reactor projects to build instead
                                    of all projects. A project can be
                                    specified by [groupId]:artifactId
                                    or by its relative path.

多分このフラグと --also-make-dependentsかは、--also-make再びこのメンテナンスの負担を軽減します。

-am,--also-make                     If project list is specified, also
                                    build projects required by the
                                    list
-amd,--also-make-dependents         If project list is specified, also
                                    build projects that depend on
                                    projects on the list

これには、2つの別個のpomを使用する場合と同じ問題があります。モジュールを定義する場所が必要です。それは私が避けようとしていることです。
カヤール

これは良い解決策です。pomを更新する必要はありません。mvn clean install -pl mysubproject
nicolas-f 2015

22

私は、デフォルトのビルドで速度に関係なく常にすべてをビルドして、POMについて詳しく理解しなくても新しい開発者がすぐに始められるようにしたいと思います。次のようなプロファイルを使用できます。

<modules>
    <module>common</module>
    <module>foo</module>
    <module>bar</module>
  </modules>
  ...
  <profiles>
    <profile>
      <id>expensive-modules-to-build</id>
      <activation>
         <activeByDefault>true</activeByDefault>
      </activation>
      <modules>
        <module>data</module>
      </modules>
    </profile>
  </profiles>
</project>

これに関する問題は、開発者がコマンドラインで別のプロファイルを指定すると、 expensive-modules-to-buildが含まれないことです(開発者も指定しない限り)。これにより、どのプロファイルを含める必要があるかを覚えておくのが難しくなります。

これを回避する方法は次のとおりです。pom.xmlファイルは常に存在するため、両方のプロファイルが常に含まれます。したがって、高価なモジュールを除外するには-P!full-build、コマンドラインで使用できます。

<profiles>
    <profile>
        <id>full-build</id>
        <activation>
            <file>
                <exists>pom.xml</exists>
            </file>
        </activation>
        <modules>
            <module>data</module>
        </modules>
    </profile>
    <profile>
        <id>short-build</id>
        <activation>
            <file>
                <exists>pom.xml</exists>
            </file>
        </activation>
        <modules>
           <module>common</module>
           <module>foo</module>
           <module>bar</module>
        </modules>
    </profile>
</profiles>

素敵な答え。しかし、2番目のコード例では本当に2つのプロファイルが必要ですか?変更されたアクティベーションエレメントを持つ最初のコード例の単一のプロファイルは機能しませんか?
Arend v。Reinersdorff、2015年

@ Arendv.Reinersdorffはい、可能ですが、この回答は、デフォルトで含めることができるビルドの他のプロファイルでも機能します。全体として、私は他の答え-pl !<module_name>,!<module_name>はこの古いものより優れていると思います
artbristol

1
良いアクティベーショントリック。常にアクティブであるとは限らない<activeByDefault>の問題を解決しました!
2016年

7

別のアイデア:Reactorモジュールはネストできるので、高速ビルドと低速ビルドのモジュールを別々のpomにグループ化し、これら2つをモジュールとして含む別のアグリゲーターpomを追加できるようにする必要があります。CIサーバーは、高速構築モジュールを含むpomのみを参照できます。

<artifactId>fast</artifactId>
<modules>
    <module>fast-a</module>
    <module>fast-b</module>
    <module>fast-c</module>
</module>

<artifactId>all</artifactId>
<modules>
    <module>fast</module>
    <module>slow</module>
</module>

1

あなたはmaven プロファイルを使用することができます。私たちのビルド環境では、プロファイルを作成しましたquick多くのプラグインとテストの実行を無効に。

これは

    <profile>
        <id>quick</id>
        <properties>
            <skipTests>true</skipTests>
            <!-- others... -->
        </properties>   
        <build>
            <plugins>
                 <!-- configuration... -->
            </plugins>
        </build>
    </profile>

次に、mavenを次のように呼び出します

mvn groupId:artifactId:goal -P quick

モジュールのpomでコンパイルやその他の標準プラグインを無効にしてスピードアップすることもできます。


2
はい、テストを無効にする場合、これはうまく機能します。しかし、pomに2つの個別のモジュールリストがない場合、どのようにプロファイルを使用してモジュールを除外できますか?私の知る限り、完全なモジュールリストを1つのプロファイルセクションに入れ、クイックビルドモジュールリストを別のプロファイルセクションに入れる必要があります。したがって、これには2つの別個のpomを使用するのと同じ問題があります。2つのモジュールリストを保持する必要があります。
カヤール、2011

モジュールを除外することは、実際にはmavenで物事を行う方法ではなく、mavenでの私の経験は、物事が行われる方法に固執する方が良いということです。モジュールを削除しますが、このモジュールの時間を短縮します。
Nr9

Mavenの問題は、「物事が行われる方法」が「現実の世界で行われる方法」と一致しないことが多く、Mavenのエクスペリエンスが貧弱で苦痛になることです。開発者は、UXトレーニングを十分に受けることができます。
エド・ランドール

0

これらの人々が求めていた答えと全く同じではありません。私の状況は、親のpomだけを展開したかったです。spring-boot-thin-layout子モジュールで使用しています。これには、親モジュールをアーティファクトにデプロイする必要があります。以下をプロジェクトに追加しました。フェーズのスキップinstalldeployフェーズを可能にします。

私の親pomで:

<properties>
    <disable.install>true</disable.install>
    <disable.deploy>true</disable.deploy>
    <enable.deployAtEnd>true</enable.deployAtEnd>
</properties>

<profiles>
    <profile>
        <id>deploy-parent</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <disable.install>true</disable.install>
            <disable.deploy>true</disable.deploy>
            <deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
        </properties>
        <build>
            <finalName>${project.version}</finalName>
        </build>
    </profile>
</profiles>

そして私の子pom(s)またはあなたが親と一緒にデプロイしたくない任意のモジュール:

<properties>
    <maven.install.skip>${disable.install}</maven.install.skip>
    <maven.deploy.skip>${disable.deploy}</maven.deploy.skip>
    <deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>

つまりmvn deploy、親pomで実行すると、すべてのモジュールがコンパイルされ、何もインストールしないで、最後に、<maven.deploy.skip>${disable.deploy}</maven.deploy.skip>プロパティに含まれていないモジュールをデプロイします。だから私の場合は親を配備するだけです。

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