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!