0
votes

I am using the makePom Ivy task to generate a Pom file for publishing to Artifactory. That works supremely except for one problem. Because namespaces are being used with our Ivy configuration, the dependencies within the pom file are not the original maven groupId/artifactId, but the namespace derived names. This causes a maven project using this pom to fail when resolving dependencies.

As an example :

Within the ivy.xml file we will have a dependency like this :

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

This has the following ivy namespace rule within 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>

This means that in a Maven repository the org="commons-configuration" and the module="commons-configuration".

When I call makePom the dependency generated will be :

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

That is an unknown artifact within the repository because it is being stored as commons-configuration:commons-configuration.

The only way I have found to get around this problem is to generate the pom within ant, then run a series of ant replaceregexp task steps across the pom before publishing. Whilst it works, it does seem quite a complex way of fixing the pom and I'm wondering if anybody has come across this, and how they got around it.

1

1 Answers

1
votes

Your solution to this problem is sound and I'm uncertain if there is a better way. It does call into question the use of ivy namespaces...

Clearly the makepom task is not namespace aware. Do you have a good reason to use them, apart from a desire to avoid editing your ivy.xml?

I would personally recommend against their use, it makes troubleshooting more complex and it's rare for the same dependency to be located in different repositories under the same name. Arguably they're two different dependencies :-) I'd be interested in learning more, this is feature I've personally never found a usecase for.

Update

If the problem is regenerating the ivy files to match Maven Central modules I could suggest the following groovy project:

https://github.com/myspotontheweb/ant2ivy