ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Oxenham <>
Subject Release time resolve ignoring integration versions
Date Tue, 13 Oct 2009 00:28:20 GMT
Long time user first time mailer. Firtly just wanted to say that IVY is awesome.

The development process I am currently using is a shared and local repository setup with integration
builds published with status of 'integration' and a version of X.X.X-devX. Dependent projects
use a revision of X.X.X+. X.X.X comes from a file that is manually incremented
by developers.

The benefit of this is that once a project is published to the shared repo the integration
builds in the local repo are ignored as Ivy resolves X.X.X over X.X.X-devX.

An example:
- Project A depends on B
- Project A currently has version 1.2.0
- Project B currently has version 2.3.1
- Project A currently has a dependency in it's ivy file of B 2.3.1+

Lets say that a developer needs to change A which also requires a change to B

The process would be this
1) Check out both projects
2) Change the file of A i.e. to 1.2.1, a minor change
3) Change the file of B i.e. to 2.4.0, a major change
4) Change A's ivy.xml to depend on B 2.4.0+
5) Develop the changes in B and then publish to the local repo. Each publish has an increasing
dev version i.e. 2.4.0-dev1, 2.4.0-dev2, 2.4.0-dev3 etc
6) Resolving from A will pick up the local revisions
7) Develop the changes in A and then publish to the local repo. Each publish has an increasing
dev version

When everything is tested and ready for release the developer needs to do the following.
8) Publish B to the shared repo. It will have revision 2.4.0
9) Publish A to the shared repo. It will have revision 1.2.1

Once this has been done the build system will no longer resolve any B integration builds from
the developers local repo. This is great as it helps to ensures reproducible builds.

*** The Problem ***
The problem with this process is that if during the release process B is not first published
to the shared repository, the publish of A will still succeed as it will pull the last integration
build of B from the local repo.

How do I get around this??

What I think would be usefull is to have the resolve task take a flag that gets it to ignore
all dependencies with status of 'integration'. So if a user forgot to do step 8 above, the
resolve in step 9 would fail.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message