Saturday, March 28th, 2009
When publishing a module, Ivy:deliver (and in turn, publish) has the ability to replace dynamic dependency revisions (e.g. ranges like “2.5+”) with the specific revisions resolved. One thing that is not very obvious is that, since the task relies on the latest resolve results to figure out what exactly those dynamic revisions are resolved to, if the latest resolve is a partial one – meaning only some of the confs are resolved, ivy:deliver may not be able to see all the resolved revisions.
I discovered this when I changed my build script to only resolve ‘master’ before publishing a snapshot to a local repo, because I wanted local publishes to be extremely fast. I guess it’s ok for local snapshots to carry dynamic revisions, but it’s probably a good idea to always do a full resolve before publishing a release.
Friday, February 13th, 2009
I put together an Ant task(download) that can use the result of the
ivy:resolve task to maintain Eclipse’s .classpath file. If your ivy:resolve also generates references to the source jars, this task will also attach them to the corresponding classpath entries in the .classpath file. more…
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!
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.