ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Miller <>
Subject Re: Ivy dependency revision for releasing vs development
Date Mon, 08 Nov 2010 17:16:55 GMT
I guess I'd have to be in your shoes to know what I'd do. The property
method could work (assuming all clients use the same version of core),
but it seems you'd need a property for each of your clients if some
use 1.0.0, and others use 1.1.0.

One thing to consider is that when you publish a module that uses a
dependency with "latest.integration", that module figures out the
latest and uses that forever. So if you published client1 a month ago,
and it used 1.0 of the core. It will always use that, no matter how
many core versions you publish. But yes, the next time you change
client1 and rebuild it, it would grab the latest.

I doubt that helps your situation, but thought it was worth mentioning.

You could set the conf to a version < 1.1.0, or whatever the next
version would be, and that might get your local copy, but not get the
next version. Or the 1.0.+, which would never grab the 1.1.0. Never
done it, but just trying to think what I'd do.


On Mon, Nov 8, 2010 at 11:46 AM, Mike Quilleash
<> wrote:
> Thanks Steve.  I've thought about your suggestions below but I think I really don't
want to ever use latest.integration in my ivy.xml.  Client releases need to stay tied to
a specific release when the core version moves on.  I'm going to explore using a placeholder
${...} in the ivy.xml for the revision of the core library and setting it to a proper version
in the projects and then maybe having an override that can be specified locally.
> Cheers.
> Mike.
> -----Original Message-----
> From: Steve Miller []
> Sent: 05 November 2010 16:57
> To:
> Subject: Re: Ivy dependency revision for releasing vs development
> 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
> <> 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 []
>> Sent: 05 November 2010 16:31
>> To:
>> 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
>> <> 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.

View raw message