Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Mike Quilleash <mike.quilleash@junifersystems.com>
To: "ivy-user@ant.apache.org" <ivy-user@ant.apache.org>
Date: Fri, 5 Nov 2010 11:51:10 -0500
Subject: RE: Ivy dependency revision for releasing vs development
Thread-Topic: Ivy dependency revision for releasing vs development
Thread-Index: Act9BvmPK1weCDuxQw6Jew72mLifIgAAlhiQ
Message-ID: 
 <8EDEDCC6C04F7E4E86BB6F6E1EAFC7EB2FB54B9612@34093-MBX-C12.mex07a.mlsrvr.com>
References: 
 <8EDEDCC6C04F7E4E86BB6F6E1EAFC7EB2FB54B95D1@34093-MBX-C12.mex07a.mlsrvr.com>
 <AANLkTikObxBL7bo3s-9+n+tZ-GEZ2QbM8UXKeV4d0PzN@mail.gmail.com>
In-Reply-To: <AANLkTikObxBL7bo3s-9+n+tZ-GEZ2QbM8UXKeV4d0PzN@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Thanks for the reply Steve.

I guess maybe this is a function of us doing releases from the same machine=
s 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.integrati=
on.  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:thatguy1177@gmail.com]=20
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.quilleash@junifersystems.com> wrote:
> Hi all,
>
> In my company we have a core project "core" and many client specific proj=
ects "client1", "client2" etc. =A0Each revision of a client project will de=
pend on a specific version of the "core" project.
>
> So I would have something like this...
>
> =A0 =A0 =A0<dependency name=3D"core" rev=3D"1.0.0"/>
>
> In the ivy.xml for my "client1". =A0This 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. =A0I 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. =A0In 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 loc=
al build/publish/retrieve/test cycle? =A0Can I perhaps in the client1 proje=
ct have a file that is not in source control and overrides the revision of =
a particular ivy dependency?
>
> Appreciate any suggestions.
>
> Mike.
>