web-dev-qa-db-ja.com

Maven WAR依存関係

受け入れテスト用のプロジェクトを作成していますが、これはさまざまな理由で、WARとしてパッケージ化された別のプロジェクトに依存しています。私はmaven-dependency-pluginを使用してWARをアンパックできましたが、アンパックされたWEB-INF/lib/*.jarおよびWEB-INF/classes/*がクラスパスに含まれるため、ビルドが失敗します。これらのファイルをクラスパスに含める方法はありますか、それともWARに依存するより良い方法はありますか？

どうもありがとう。

mavenmaven-2warmaven-dependency-plugin
79
deelo55

Maven-war-plugin 2.1-alpha-2以降、別のオプションがあります。 WARプロジェクトで：

<plugin>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.1.1</version>
    <configuration>
        <attachClasses>true</attachClasses>
    </configuration>
</plugin>

これにより、受け入れテストプロジェクトで使用できるクラスアーティファクトが作成されます。

<dependency>
    <groupId>your-group-id</groupId>
    <artifactId>your-artifact-id</artifactId>
    <version>your-version</version>
    <classifier>classes</classifier>
</dependency>
110
Christoph Leiter

実際、設計上、Mavenはプロジェクトの依存関係として宣言された戦争の推移的な依存関係を解決しません。それについて実際に問題があります MNG-1991 ですが、Maven 2.xおよび わからない オーバーレイでこの問題を回避できるかどうかはわかりません。提案された解決策の私の理解は、例えばpomタイプのプロジェクトで依存関係を複製することです。

（編集：さらに掘り下げた後、 このスレッド で何か面白いものを見つけました。

私は先月、AppFuseプロジェクトの開発を手伝い、Maven戦争プラグインの戦争オーバーレイ機能を多用しています。それは本当に気の利いた機能です！

ウォーオーバーレイを最大限に活用するために、プロジェクトで完全な依存関係としてウォーアーティファクトを使用できるWarpathプラグインを開発しました。簡単に言うと：

1）war依存アーティファクトの/ WEB-INF/classesディレクトリの内容は、通常のコンパイルなどのタスクのプロジェクトのクラスパスに含めることができます。
2）war依存アーティファクトからの推移的な依存関係は、他のプラグインで使用できるようになります。コンパイルとイヤ-スキニー戦争を作成するときにすべての依存関係を含める必要がなくなりました！

このプラグインは、ここ数か月間AppFuseプロジェクトで積極的に使用されており、使いやすく安定した状態にあると感じています。 warプラグインチームはwarプラグイン内にwarpath機能を含めることに興味がありますか？それをホストするのに最も自然な場所のようです。

そのため、私はそれを使った経験はありませんが、 maven warpath plugin は実際には見栄えがよくシンプルで、中央リポジトリで利用可能です。使用するには、次のプラグイン構成要素をpom.xmlファイル：

[...]
<build>
  <plugins>
    <plugin>
      <groupId>org.appfuse</groupId>
      <artifactId>maven-warpath-plugin</artifactId>
      <version>1.0-SNAPSHOT</version>
      <extensions>true</extensions>
      <executions>
        <execution>
          <goals>
            <goal>add-classes</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
[...]

そして、クラスパスに含めたい戦争依存関係をwarpathタイプ依存関係として追加します。

[...]
<dependencies>
  <dependency>
    <groupId>org.appfuse</groupId>
    <artifactId>appfuse-web</artifactId>
    <version>2.0</version>
    <type>war</type>
  </dependency>
  <dependency>
    <groupId>org.appfuse</groupId>
    <artifactId>appfuse-web</artifactId>
    <version>2.0</version>
    <type>warpath</type>
  </dependency>
</dependencies>
[...]

Warおよびwarpathの両方の依存タイプが必要です：warタイプは、Maven warプラグインがwarオーバーレイを行うために使用され、warpathタイプは、warpathプラグインがプロジェクトクラスパスに含めるためのアーティファクトの正しいリストを決定するために使用されます。

試してみます）

23
Pascal Thivent

overlays を使用します。まず、テストプロジェクトにはwarもパッケージ化する必要があります。

テストする戦争プロジェクトの依存関係を宣言します。

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>your-project-arftifactId</artifactId>
    <version>${project.version}</version>  
    <type>war</type>
    <scope>test</scope>
</dependency>

次に、maven-war-pluginオーバーレイを構成します。

<plugins>
    <plugin>
        <groupId>org.Apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
            <webResources>
                <resource>
                    <directory>${basedir}/src/main/webresources</directory>
                    <filtering>true</filtering>
                </resource>
            </webResources>
            <overlays>
                <overlay/>
                <overlay>
                    <groupId>your.group</groupId>
                    <artifactId>your-project-artifactId</artifactId>
                </overlay>
            </overlays>
        </configuration>
    </plugin>

上記のテストプロジェクトの例では、webresources構成ファイル（conxtextなど）を上書きします。

EDIT：このソリューションはMaven 3ではテストされていません。

13
cetnar

良い点、ジャスティン。つまり、実際に問題を解決することができました。つまり、アセンブリに戦争を含めることと、そのすべての推移的な依存関係を含めることです。 AssemblyプラグインがそのgroupId/artefactIdによって参照されるjarを見つけられないため、戦争依存を「jar」として複製できませんでしたが、

  • タイプとして戦争依存を複製するpom

動作します！戦争とその推移的な依存関係はアセンブリに含まれていません。 （現在表示されている）pomファイルを除外するには、次のようなexclude要素を追加する必要がありました。

  <excludes>
    <exclude>*:pom</exclude>
  </excludes>

assembly.xmlファイルに追加します。

これは、このスレッドの元の質問に対する回避策にもなり得ると思います。

4
Niels