web-dev-qa-db-ja.com

Mavenが解決を試みる前に、ライフサイクルの一部としてローカルjar依存関係をインストールします

2つの依存関係の間にいくつかの非互換性があるため、依存関係の1つのシェーディングバージョンを作成する必要がありました。これは、私のプロジェクトがローカルの.jarファイルに依存していることを意味します。

以前は、mvn install-fileを実行する前に、mvn installを使用してこの.jarをローカルリポジトリにインストールするだけで完全に問題ありませんでした。

mvn org.Apache.maven.plugins:maven-install-plugin:2.5.2:install-file -Dfile=lib/my-custom-jar-1.0.0.jar
mvn install

ただし、私のプロジェクトは自動ビルドサーバー上にあり、mvn clean installのみを実行します。

長い間探して、私はいくつかの解決策を見つけましたが、どれも完璧ではありません。

私は以下の答えとして見つけた解決策を書き留めますが、誰かがこの問題を解決するためのより良いアイデアを持っていることを願ってこの質問を投稿します。

javamavenmaven-install-plugin
17
Wiwiweb

これが私が試したいくつかの解決策ですが、私の使用には適していませんでした：

1.maven-install-plugin

アイデアは、これをpomに追加することにより、インストールライフサイクルの一部としてインストールファイルの目標を追加することです。

<plugin>
  <artifactId>maven-install-plugin</artifactId>
  <version>2.5.2</version>
  <executions>
    <execution>
      <phase>validate</phase>
      <goals>
        <goal>install-file</goal>
      </goals>
      <configuration>
        <file>lib/my-custom-jar-1.0.0.jar</file>
      </configuration>
    </execution>
  </executions>
</plugin>

[...]

<dependency>
  <groupId>org.me</groupId>
  <artifactId>my-custom-jar</artifactId>
  <version>1.0.0</version>
</dependency>

ただし、最初の目標であるvalidateでも、Mavenはinstall-fileが実行される前に依存関係を解決しようとします。

クリーンな目標を使用するというアイデアを見ました。厄介なことに、これは別々のコマンド（mvn clean && mvn install）を実行する場合に機能しますが、1つのmvnコマンド（mvn clean install）で両方を実行すると、Mavenが最初に依存関係を解決します。これに対する解決策はありますか？

2.マルチモジュールプロジェクト

このStack Overflowの回答に見られる という考え方は、親pomにinstall-fileを作成し、子pomに依存関係を追加するというものです。 Mavenは依存関係を個別に解決するだけなので、これは機能するはずです。

しかし、私のプロジェクトは単一のモジュールであり、この問題を解決するためだけに偽の親を作成することは、過度の複雑さと醜いハックのように思えます。

3.basedirを使用したシステムスコープ

<dependency>
  <groupId>org.me</groupId>
  <artifactId>my-custom-jar</artifactId>
  <version>1.0.0</version>
  <scope>system</scope>
  <systemPath>${basedir}/lib/my-custom-jar-1.0.0.jar</systemPath>
</dependency>

これはまさにこの種の状況のた​​めに作成されたように見えますが、システムスコープは実際には、プロジェクトを実行するすべてのシステムに依存関係があることを想定しているため、.warにパッケージ化されず、プロジェクトが非-機能的。

4.addjars-maven-plugin

このカスタムプラグインはここにあります 。warファイルに.jarが含まれ、コンパイル中にpomに追加されます。

<plugin>
  <groupId>com.googlecode.addjars-maven-plugin</groupId>
  <artifactId>addjars-maven-plugin</artifactId>
  <version>1.0.5</version>
  <executions>
    <execution>
      <goals>
        <goal>add-jars</goal>
      </goals>
      <configuration>
        <resources>
          <resource>
            <directory>${basedir}/lib</directory>
            <includes>
              <include>**/my-custom-jar-1.0.0.jar</include>
            </includes>
          </resource>
        </resources>
      </configuration>
    </execution>
  </executions>
</plugin>

これはほとんどの通常の場合に機能します。ただし、実際のpomではカスタム.jarへの依存関係を示さないため、IDEには多くのクラスが欠落しているため、カスタムを手動で追加する必要があります。外部ライブラリとしてのjar。

これはまだややハッキーであり、いくつかの特別なケースでは機能しません（たとえば、Jenkinsデバッグ用のhpi：runはいくつかのエラーをスローします）。さらに、コードがサードパーティのプラグインに依存しないことを好みました。

5.ディレクトリ内のMavenリポジトリ

この投稿を作成した後にこの解決策を見つけました、そして私はそれにかなり満足しています。

これは、私の質問でmvn install-fileコマンドを実行した場合とほぼ同じ結果ですが、プロジェクト内にあるリポジトリにカスタムライブラリをインストールして、結果を保存し、プロジェクトの一部として保持する点が異なります。

このコマンドを使用して、ライブラリをプレインストールする必要があります。

mvn org.Apache.maven.plugins:maven-install-plugin:2.5.1:install-file \
-Dfile=lib/cloudfoundry-client-lib-shaded-1.0.3.jar \
-DlocalRepositoryPath=lib

これが完了すると、リポジトリがlibフォルダーに作成され、このコマンドを再度実行する必要がなくなります。

このリポジトリをpomで使用することを示します。

<repository>
  <id>Local repository</id>
  <url>file://${basedir}/lib</url>
</repository>

[...]

<dependency>
  <groupId>org.me</groupId>
  <artifactId>my-custom-jar</artifactId>
  <version>1.0.0</version>
</dependency>

このソリューションでは、SCMに多数の追加フォルダーをコミットする必要がありますが、それは私にとって管理可能な欠点であり、私はこれに満足しています。

38
Wiwiweb

1つのサブプロジェクト（Sと呼びます）でシェード実行を実行すると、問題の依存関係のバージョン（a）が消費され、独自のG/A/Vの結果が生成されます。サブプロジェクトのメイン出力を生成するようにシェードを構成します。言い換えると、Sはgroup：artifact：versionを生成します。これらはすべて、開始するものの座標とは完全に異なり、2つのバージョンが必要です。

他のサブプロジェクトでは、シェーディングされたバージョンを取得するための依存関係として（S）を宣言するだけで、シェーディングされていない他のバージョンを宣言することもできます。

これはすべて、シェーディング時にパッケージの名前を変更したことを前提としています。

Install：anythingの必要はありません。

1
bmargulies