True, we have a separate box. If I were to build a release from my machine, I would make a "release" ant task that would either: 1) Clear my local repository before building. 2) Point to a different ivy settings file that didn't include the local repo.
If I think of something else, I'll let you know. On Fri, Nov 5, 2010 at 12:51 PM, Mike Quilleash <mike.quille...@junifersystems.com> wrote: > Thanks for the reply Steve. > > I guess maybe this is a function of us doing releases from the same machines > that we develop on (small company!) so in my case the release can "see" a > local repository with dev releases which would be bad for latest.integration. > I'm guessing in your case your release builds are done on a dedicated > machine so you don't get this problem? > > Cheers. > > Mike. > > -----Original Message----- > From: Steve Miller [mailto:thatguy1...@gmail.com] > Sent: 05 November 2010 16:31 > To: ivy-user@ant.apache.org > Subject: Re: Ivy dependency revision for releasing vs development > > Hi Mike, > > The way I do it is to always use latest.integration when referring to > other modules that I publish. That way, the release build will pick up > the latest revision in my shared repository. But if I need to change > both modules, I do what you said, publish the "core" to the local > repo, and so my dev environment will pick up the local copy. > > If there are better ways, please let us know, but this seems to work > pretty well for me. > > Steve > > On Fri, Nov 5, 2010 at 12:18 PM, Mike Quilleash > <mike.quille...@junifersystems.com> wrote: >> Hi all, >> >> In my company we have a core project "core" and many client specific >> projects "client1", "client2" etc. Each revision of a client project will >> depend on a specific version of the "core" project. >> >> So I would have something like this... >> >> <dependency name="core" rev="1.0.0"/> >> >> In the ivy.xml for my "client1". This is all fine. >> >> Now I if happen to be making a change to core and wanting to test client1 >> against it I do the following. >> >> - Change core >> - Run core publish build step to publish to a local resolver >> - Change client1 ivy.xml to latest.integration >> - Run client1 retrieve build step to pull local version of core >> - Test client1 with new core version >> >> Now the bit I don't like is changing the ivy.xml. I don't mind editing the >> file as such but it's easy to check it back to source control with the >> revision set to latest.integration at which point the next build will not be >> using 1.0.0 anymore. In my mind the ivy.xml should only be touched to >> change 1.0.0 -> 1.1.0 or similar. >> >> How can I avoid touching the source-controlled copy of ivy.xml in the local >> build/publish/retrieve/test cycle? Can I perhaps in the client1 project >> have a file that is not in source control and overrides the revision of a >> particular ivy dependency? >> >> Appreciate any suggestions. >> >> Mike. >> >
