Following up Keith's response... Certainly, it's a good practice to use a revision suffix to distinguish integration builds from milestone/release builds. For example: 1.0-SNAPSHOT as opposed to 1.0-alpha1 or 1.0 (release)
And technically, you can make a property placeholder part of a dependency@rev value in an ivy.xml. However, in practice, picking up all or part of the dependency's rev attribute from a property introduces a layer of indirection that probably doesn't gain you anything at the cost of inconvenience, potential errors introduced by having more moving parts, and worst of all, potentially losing reproducibility on your release builds. If you're a developer working against trunk or an integration branch (to use the Subversion terms), you're going to want to see right in your ivy.xml whether you're depending on 1.0-SNAPSHOT (or latest.integration) or 1.0 (or latest.release) of something rather than having to look up a property elsewhere to figure out what you're depending on. And when you're getting ready to make a release (whether milestone or release) out of a build on an integration branch, you'd want to have the control that comes with manually removing the -SNAPSHOT suffix from your dependencies one by one to make sure the dependency still works. Even if you have an automated mechanism to make sure that, in preparation for a release, all the dependency revisions identifying milestone/release dependencies have the suffix stripped, that's still going to be a one-off change that never has to be controlled subsequently. The milestone and release ivy.xml files, within immutable projects as represented by tags in source control, will and should have hardcoded revisions in their dependencies. They'll never change once they're tagged. As for the potentially cool feature of switching back and forth between latest.integration and latest.milestone and latest.release based on one property, keep in mind that even though your current project is integration, that doesn't necessarily mean that its dependencies are all integration. And where you do have some release-worthy dependencies, you're in a position to know and just specify the hardcoded version. Putting latest.milestone and latest.release in the dependencies when you're ready to tag a release (whether milestone or release) really doesn't buy anyone anything. No one is doing active development against a tag and at this point you know precisely what the revisions you're depending on are. Worst, it's a serious mistake to say "Give me the latest release for a dependency" rather than "Give me this particular release for a dependency" on a release build because that puts your release at the mercy of whatever the latest is in the Ivy repository. This means that you've created a release for foo 1.0 that depends on bar 2.0. Subsequently bar 2.1 comes out. Then when you go to release foo 1.0, you get bar 2.1 for latest.release, which is not what you wanted. You've just lost the reproducibility on your release builds. On Thu, Mar 24, 2011 at 7:08 AM, Keith Hatton < [email protected]> wrote: > The value in the rev="..." attribute can be a property, so you can have, > for example, rev="latest.${foo}" in your ivy.xml, and work out what the > value of ${foo} should be in your Ant script (just make sure you do this > prior to calling any <ivy:...> tasks). > > HTH > Keith > > > -----Original Message----- > From: Alex Kiesel [mailto:[email protected]] > Sent: 24 March 2011 11:56 > To: ivy-user > Subject: Different dependencies for integration, milestone, release > > Hi, > > I'd like to deploy a build system on top of Ivy. Currently, I face one > problem: I'd like to have different dependencies when integration, > milestone or release is built. A release should only depend on other > releases, milestones should require releases and/or milestones and > integration build may take anything. > > I'd like to leave the rev="" setting in the dependency untouched. Is > there one parameter to <ivy:resolve> that would help me? > > Regards, > -Alex > >
