更新

Question

我正在使用makePom Ivy任务生成一个Pom文件，用于发布到Artifactory。除了一个问题外，这个工作非常有用。因为命名空间与我们的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

中有以下常春藤命名空间规则

<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 任务步骤。虽然它有效，但它似乎确实是一种修复pom的复杂方式，我想知道是否有人遇到过这个问题，以及他们是如何解决这个问题的。

Answer 1

你对这个问题的解决方案是合理的，我不确定是否有更好的方法。它确实对ivy namespaces ...

的使用产生了疑问

显然，makepom任务不支持名称空间。除了希望避免编辑ivy.xml之外，你有充分的理由使用它们吗？

我个人建议不要使用它，它会使故障排除变得更加复杂，并且很少有相同的依赖项位于同名的不同存储库中。可以说它们是两种不同的依赖关系:-)我有兴趣了解更多，这是我个人从未找到用例的功能。

更新

如果问题是重新生成常春藤文件以匹配Maven Central模块，我可以建议以下groovy项目：

https://github.com/myspotontheweb/ant2ivy

当使用名称空间时，Ivy makePom依赖项

1 个答案:

更新