0

Artifactory に発行する Pom ファイルを生成するために makePom Ivy タスクを使用しています。1つの問題を除いて、それは最高に機能します。名前空間は Ivy 構成で使用されているため、pom ファイル内の依存関係は元の maven groupId/artifactId ではなく、名前空間から派生した名前です。これにより、依存関係を解決するときに、この pom を使用する Maven プロジェクトが失敗します。

例として:

ivy.xml ファイル内には、次のような依存関係があります。

<dependency 
  org="org.apache.commons" 
  name="commons-configuration" 
  rev="1.6" 
  conf="compile->compile(*),master(*);runtime->runtime(*)" />

これには、ivysettings.xml 内に次の ivy 名前空間ルールがあります。

<rule>
  <fromsystem>
    <src org="org.apache.commons" module="(commons-configuration)" />
  </fromsystem>
  <tosystem>
    <src org="commons-.+" module="commons-.+" />
    <dest org="org.apache.commons" module="$m0" />
  </tosystem>
</rule>

これは、Maven リポジトリで org="commons-configuration" および module="commons-configuration" であることを意味します。

makePomを呼び出すと、生成される依存関係は次のようになります。

<dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-configuration</artifactId>
      <version>1.6</version>
      <scope>runtime</scope>
    </dependency>
</dependencies>

commons-configuration:commons-configuration として保存されているため、これはリポジトリ内の不明なアーティファクトです。

この問題を回避するために私が見つけた唯一の方法は、ant 内で pom を生成し、公開する前に pom で一連の ant replaceregexpタスク ステップを実行することです。それは機能しますが、ポンポンを修正するのは非常に複雑な方法のようです.

4

1 に答える 1

1

この問題に対するあなたの解決策は健全であり、より良い方法があるかどうかはわかりません。それはアイビー名前空間の使用に疑問を投げかけます...

明らかに、makepoタスクは名前空間に対応していません。ivy.xml を編集したくないという願望以外に、それらを使用する正当な理由はありますか?

個人的には使用しないことをお勧めします。トラブルシューティングがより複雑になり、同じ依存関係が同じ名前で異なるリポジトリに配置されることはめったにありません。おそらく、それらは2つの異なる依存関係です:-)もっと知りたいと思います.これは、私が個人的にユースケースを見つけたことのない機能です.

アップデート

問題が Maven Central モジュールに一致するように ivy ファイルを再生成している場合は、次の groovy プロジェクトを提案できます。

https://github.com/myspotontheweb/ant2ivy

于 2013-02-20T08:54:18.887 に答える