web-dev-qa-db-ja.com

maven-Assembly-plugin:appendAssemblyIdの使用方法

マルチモジュールMavenプロジェクトがあり、1つのモジュールでビルド中に2つのアーティファクトを作成します。

  • 他のモジュールのいくつかが依存するjarライブラリーである主要な成果物。
  • いくつかのヘルパー機能を実行する実行可能なjarファイル。他のモジュールはこれに依存せず、特定の状況でユーザーが手動で実行することのみを目的としています。

maven-Assembly-pluginプラグインを構成するために使用するコードは次のとおりです。

<plugin>
    <artifactId>
        maven-Assembly-plugin
    </artifactId>
    <version>2.4</version>
    <executions>
      <execution>
        <id>dist-Assembly</id>
        <phase>package</phase>
        <goals>
          <goal>single</goal>
        </goals>

        <configuration>
          <finalName>bso</finalName>
          <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>
          <finalName>helper-${project.version}</finalName>
          <appendAssemblyId>false</appendAssemblyId>
          <archive>
            <manifest>
              <mainClass>HelperMain<mainClass>
            </manifest>
          </archive>
        </configuration>

      </execution>
    </executions>
  </plugin>

appendAssemblyIdfalseに設定します。そうしないと、-jar-with-dependenciesが最終名に追加され、その必要性がわかりません。省略すると、よりクリーンで使いやすいファイル名になります。

mvn integration-testを実行すると、次の警告が表示されます。

[警告]構成オプション:「appendAssemblyId」はfalseに設定され、「分類子」はありません。アセンブリファイル[...]/target/helper-5.0.0-SNAPSHOT.jarを添付する代わりに、メインプロジェクトアーティファクトのファイルになります。

注:このプロジェクトに複数の記述子または記述子形式が提供されている場合、このファイルの値は非決定的です!

[警告]既存のプロジェクトメインアーティファクトファイル:[...]/target/my.module-5.0.0-SNAPSHOT.jarをアセンブリファイル:[...]/target/helper-5.0.0-に置き換えるSNAPSHOT.jar

私をイライラさせるものが2つあります。

  1. 警告はmy.module-5.0.0-SNAPSHOT.jarをhelper-5.0.0-SNAPSHOT.jarに置き換えると主張しているという事実にもかかわらず、実際にはそうではなく、ビルドが終了しても両方のファイルのサイズは異なります。

  2. アーティファクトの交換に関する警告が表示されるのはなぜですか?

  3. classifierは非推奨になっているようです。なぜ警告で使用するように求められますか?

21
lanoxx

これは、警告を誤って解釈しているためです。


要約しましょう。タイプpomではないMavenプロジェクトは、デフォルトで常にメインアーティファクトと呼ばれるものを生成します。 JARの場合、このアーティファクトは、コンパイルされたソースをJARにパッケージ化した結果です。 WARの場合、これはWebアプリケーションを構築した結果です。

覚えておくべき重要なことは、このアーティファクトはプロジェクトにattachedであるということです:この用語はプロジェクトをインストールするときに便利です(_mvn install_を使用) 、デプロイ済み(_mvn deploy_)またはリリース済み(_maven-release-plugin_)。 Attachedは、このアーティファクトがプロジェクトのインストール時にインストール/デプロイ/リリースされることを意味します。 Mavenビルド中に生成されるすべてのファイル(基本的に、targetフォルダーの下にあるすべて)はそうではありません。添付されたファイルのみ。そのため、targetの下に多くのファイルを非常にうまく作成できますが、単一のアーティファクトがインストールされています。

この主なアーティファクトと並んで、ビルドでインストールまたはデプロイする他のアーティファクトを生成することができます。それは、追加または二次的に付加されたアーティファクトの概念です。主な例はJavadocまたはソースです。通常、プロジェクトがリリースされると、そのJavadocとそのソースもリリースされます。そして、それは 概念classifierキックイン です。

Mavenリポジトリでは、すべてのファイルが同じ命名規則に従う必要があります:artifactId-version(-classifier).type。すべてのセカンダリアーティファクトは、メインアーティファクトと同じGAV(グループID、アーティファクトID、バージョン)を持つため、Mavenリポジトリ1のメインアーティファクトと1つの添付アーティファクト(メインJARの場合のように)内に配置する場合JAR JavadocおよびJARソースを使用して)、それらを区別する何らかの方法が必要です。 classifierの目的は次のとおりです。メインアーティファクトとセカンダリアーティファクトを区別します。


例に戻りましょう。 jarパッケージであるMavenプロジェクトは、デフォルトで_my.module-5.0.0-SNAPSHOT.jar_というメインのJARアーティファクトを生成します。まだデフォルトでは、このメインJARはプロジェクトにアタッチされています(インストール/デプロイの準備ができています)。ここで、_maven-Assembly-plugin_を構成して、新しいJAR成果物(_helper-5.0.0-SNAPSHOT.jar_と呼ばれますが、実際には問題ではありません)を作成します。アセンブリプラグインは、デフォルトでは、 生成するアーティファクトをプロジェクトにアタッチします 。したがって、最終的に2つの成果物がアタッチされます。

  1. _my.module_という同じアーティファクトIDを持つ; targetフォルダー内のディスク上のファイルの名前がhelperであるという事実は無関係であり、GAV座標のみが重要です。
  2. 同じバージョンの_5.0.0-SNAPSHOT_を持っている
  3. jARの同じパッケージを持っている

そしてそれらを区別する分類子はありません。これが警告を発生させるものです。同じ座標を持っているという理由だけで、メインのアーティファクトを効果的に置き換えるセカンダリアーティファクトをプロジェクトにアタッチすることになります。結果は次のとおりです。

  1. 両方のファイルはtarget内のディスク上で異なる名前を持っていますが、それは無関係です。
  2. 両方が同じ座標を共有するため、1つだけが生き残ります。

競合に勝ち、添付されたメインアーティファクトを置き換えるのは、アセンブリプラグインによって生成されたものです。

すべてを理解したい場合は、プロジェクトで_mvn clean install_を実行し、ローカルリポジトリを確認してください。 _jar-with-dependencies_アーティファクトのみがインストールされることに気付くでしょう。もう1つ(主要なアーティファクト)が馬鹿になりました。

_<distributionManagement>_を設定することもできます:

_<distributionManagement>
    <repository>
        <id>local-repo-test</id>
        <url>file://...</url>
    </repository>
</distributionManagement>
_

_mvn clean deploy_を呼び出します。その後、デプロイされたアーティファクトが_jar-with-dependencies_のみであることを確認できます。


最後の注意:はい、Assembly Pluginの classifier パラメーターは非推奨です。これは、Assembly idを分類子として使用するだけだからです。

34
Tunaki