Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of roger.parkinson35@gmail.com
 designates 209.85.210.45 as permitted sender)
Received-SPF: pass (google.com: domain of roger.parkinson35@gmail.com
 designates 10.68.196.195 as permitted sender) client-ip=10.68.196.195;
Message-ID: <4F42B2E4.6020408@gmail.com>
Date: Tue, 21 Feb 2012 09:53:56 +1300
From: Roger <roger.parkinson35@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: ivy-user@ant.apache.org
Subject: Re: avoiding cleaning the cache all the time
References: 
 <CADdD2zoSv-nO=sBeiKTRF8Y2RXtk95s3H3OeBCyB1kT9cDXNVA@mail.gmail.com>
In-Reply-To: 
 <CADdD2zoSv-nO=sBeiKTRF8Y2RXtk95s3H3OeBCyB1kT9cDXNVA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

We get past this by always changing the version.

So that we can identify interrum versions, as opposed to proper 
releases, easily we have a convention
that looks like 1.2.rc2 1.2.rc3 ... (rc stands for 'release candidate' 
but you can use whatever convention you like)

We do try to minimise the rc releases by adding lots of unit tests to 
the project. We find that often rc releases are used just to test
a change and then the developer goes around again. It is better to write 
a unit test in the LibX project that reproduces the issue
and then do all the developer cycles in LibX rather then generating rc 
releases. The advantage is that you have the unit test
in the project and you can use it in regression tests.

It isn't always possible to do what you need to do in a unit test 
though, so you have to compromise sometimes.

R

On 20/02/12 13:46, Sugar Bzzz wrote:
> Hello,
>
> I have two projects: LibX and AppY, where AppY depends on LibX.
>
> I would like to establish the following workflow with Ivy:
>    1) make some changes to LibX
>    2) rebuild and publish the modified LibX using Ant+Ivy
>    3) rebuild AppY using the modified LibX
>    4) repeat (goto 1)
>
> This works the first time around (with a clean cache) but it doesn't work a
> second time. When I rebuild AppY a second time around, it uses a cached
> LibX from the first iteration of this workflow. The only way I can get the
> latest LibX when building AppY after publishing LibX once already, is to
> clean the Ivy cache and start over; but this takes a long time since all of
> the dependencies of LibX need to be redownloaded. I want AppY to use the
> latest LibY that I've built.
>
> How can I achieve this without having to clean the Ivy cache every time I
> modify LibX?
>
>
> Thanks.
>
>
> Here is how I have Ant and Ivy setup:
>
> in build.xml of LibX:
>
>    <target name="publish" depends="jar" description="-->  publish LibX">
>      <ivy:publish pubrevision="${LibX.version}" resolver="local"
> overwrite="true">
>        <artifacts pattern="${artifacts.dir}/[artifact].[ext]"/>
>      </ivy:publish>
>    </target>
>
> in ivy.xml of LibX:
>
> <ivy-module version="2.2">
>      <info organisation="myorg" module="LibX"/>
>      <publications>
>          <artifact name="LibX" type="jar"/>
>      </publications>
>      <dependencies>
>          <... several dependencies here ...>
>      </dependencies>
> </ivy-module>
>
> in build.xml of AppY:
>
>    <target name="resolve" description="-->  retrieve dependencies">
>      <ivy:retrieve/>
>    </target>
>
> in ivy.xml of AppY:
>
> <ivy-module version="2.2">
>      <info organisation="myorg" module="AppY"/>
>      <dependencies>
>          <dependency org="myorg" name="LibX" rev="latest.integration"/>
>      </dependencies>
> </ivy-module>
>