Overriding an Ivy dependencies' revision

Question

Hi all,

I use Apache Ivy for handling library dependency. In my company we have a "core" project which is released/versioned periodically. We then have many "customer" projects which are for a particular client. Each customer project uses a particular version of the core project which we maintain in the ivy.xml of the customer project. All fine.

Sometimes someone will want to change core locally and test the change with a specific project. In that instance they will build the core and publish it to a local Ivy repo, rather than the shared one.

In order to have this locally built version picked up do I need make sure the locally built version or core publishes with the exact same x.y.z version as the project is pointing at in ivy.xml? Or is there some other approach? I'd rather not have people required to fiddle with the ivy.xml (e.g. change it to core -> latest.integration) as that's the sort of change that gets checked in to source control by accident. Maybe there's some way of overriding the revision of a dependency in ivy.xml, perhaps in a local properties file?

Answer 1

In development I always specify my internal project dependencies as either "latest.integration" or "latest.release". This solves the problem of not fiddling with the files checked into source control.

The good news is that the ivy publish task will resolve dynamic revision numbers for you. Check the ivy.xml file that is published to your repository and you'll see the latest revision numbers (at time of publication) have been automatically substituted.

The ivy deliver task is designed to do this for you within your build. I use it when I need a resolved ivy file to generate a Maven POM file for my module.

For example:

<ivy:deliver pubrevision="??" status="release" deliverpattern="${build.dir}/ivy.xml"/>
<ivy:makepom ivyfile="${build.dir}/ivy.xml" pomfile="${build.dir}/pom.xml"/>

My final tip is to use the ivy buildnumber when you need to know the next version number in a sequence. Ivy will work this out based on what is already published to the ivy repository (Much more flexible that the standard ANT build number task which relies on property files).

So continue to use dynamic revisions and let ivy work out the actual version numbers in a particular release.