Fix broken maven-metadata.xml through Nexus

Saturday, January 17th, 2009

The log4j maven-metadata.xml hosted at ibiblio is missing the latest two versions, 1.1.14 and 1.1.15. It becomes a problem for me as an Ivy user, too, since Ivy 2.0 adds the ability to use maven metadata to list available versions.

Fortunately I have a Nexus repository as the aggregator/proxy to all the external repositories. Brian from the Nexus IRC room pointed me to this solution/workaround: add the fixed maven-metadata.xml to a repo hosted by Nexus – e.g., the “3rd Party” repo coming out of box in Nexus. Then create a group to aggregate the 3rd Party and the public Ibiblio repos. The “virtual” group repo will automatically create a merged maven-metadata.xml on the fly whenever it is requested.

And it works like a charm. Thanks, Brian!

Why does the GWT compiler require an X server and how to work around it

Monday, May 12th, 2008

Got this error today when trying to build our little GWT application in linux: more…

Ivy 2 beta 2 Adds Maven Metadata Support

Tuesday, March 18th, 2008

Ivy 2.0 beta 2 adds an interesting useMavenMetaData switch to its ibiblio resolver. When it’s on (the default actually), Ivy will try and use the maven-metadata.xml for listing the versions available, and for dynamic dependency resolution. This is interesting to me because it makes it a lot easier to run our builds against a proxy repository server like Maven Proxy or Archiva.

Until beta 2, Ivy finds out about the available versions of a module by parsing the directory listing HTML from Ibiblio’s Apache server. That doesn’t work when there is a proxy server sitting in between, because a) the proxy server doesn’t usually proxy directory listing requests, and/or b) the proxy server renders the directory listing in different HTML. Switching to using the structured maven meta data completely eliminated this mess.

Of course, using the maven-metadata.xml files from the official ibiblio repository will subject us to some new hazard – some modules have out-of-date maven-metadata.xml. For instance, by its maven-metadata.xml, the latest version of Hibernate would still be 3.2.0.cr1.

One of those maven proxy servers turns out to be a perfect solution to this problem – we can use them now, remember? :) In my case, I run an Archiva server proxying the official maven 2 repository. Whenever I run into a bad metadata file, I simply request the missing version through Archiva, and it will fetch it and update the metadata file. For example, in the hibernate case, I would just open up Firefox and try to download http://archiva-server/repository/internal/org/hibernate/hibernate/3.2.6.ga/hibernate-3.2.6.ga.jar. That only needs to be done once, and afterwards Archiva would have updated its local version of the maven-metadata.xml properly.