Choose Rev from Ant Build File

Question

I am looking to separate development and production environments by publishing jars to ivy with live and dev qualifiers.

I am looking for a way to trigger ivy from projects that have these dependencies to automatically grab the latest from these environments based on the ant build file.

I am new to ant and ivy and am not finding documentation on if this is possible or not.

Basically, build-live in ant would trigger resolve-live that would use ref="[1.live.0,)", however we would also need a default one for developers in an Eclipse environment to automatically pick up dependencies through the plugin.

Answer 1

You have not indicated what type of repository you are using. I'm going to assume you are not using a Maven repository manager to manage your release repository. Some of these support remote workflow to manage what I like to call "release candidates" (for an example take a look at the staging feature provided by Sonatype Nexus)

For a pure ivy solution I first recommend reading the best practice documentation, specifically the section titled "Dealing with integration versions".

When publishing a new ivy module version one can set the status field. Out of the box ivy supports "integration", "milestone" or "release" but even these can be extended. The status is a label or metadata attribute that appears in the info field of the published ivy file within the ivy repository.

How does this work? When publishing the module as follows:

<ivy:publish resolver="???" pubrevision="1.0.1" status="integration">
   <artifacts pattern="build/artifacts/jars/[artifact].[ext]" />
   <artifacts pattern="build/artifacts/zips/[artifact].[ext]" />
</ivy:publish>

This states that the release 1.0.1 is an integration release.

This then enables the functionality you're looking for. Ivy's dynamic revisions capability can be used to automatically download the latest version with a particular status as follows:

<dependency org="acme" name="foo" rev="latest.integration" />

Update

Once a module is published into the repository it cannot be changed. Doing so could potentially break builds that rely on that version. Think about, if you change the status of a build how to communicate that change? Instead you use the "status" to indicate how stable a version is. Open source projects will frequently publish several "general availability" or "milestone" releases before the finally approved major version.

To do what you want to do requires server-side repository file management. I recommend looking at the "staging" suite in Sonatype Nexus. This feature keeps each pending release in a temp repo until it's finally approved and merged into the main release area.