0

我正在使用 makePom Ivy 任务生成一个用于发布到 Artifactory 的 Pom 文件。除了一个问题外，这非常有效。因为命名空间与我们的 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任务步骤。虽然它有效，但它似乎是一种修复 pom 的相当复杂的方法，我想知道是否有人遇到过这个问题，以及他们是如何解决这个问题的。

4

1 回答 1

1

您对这个问题的解决方案是合理的，我不确定是否有更好的方法。它确实对常春藤名称空间的使用提出了质疑......

显然，makepom任务不知道命名空间。除了避免编辑您的 ivy.xml 之外，您是否有充分的理由使用它们？

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

更新

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

https://github.com/myspotontheweb/ant2ivy

于 2013-02-20T08:54:18.887 回答