ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject RE: cache problems
Date Wed, 06 Feb 2008 15:26:02 GMT
In order to have globally unique rev numbers, I would need to put things like branch and status
into the rev number.  How do I do that?  I already tried using [branch] and [status] in the
pubrevision attribute on my publish task, but they don't get resolved.  I am currently calling
ivy's buildnumber task so that I can format my rev numbers like yyMMdd.#:

        <format property="dateStamp" pattern="yyMMdd"/>
<ivy:buildnumber organisation="Landmark" module="${}" revision="${dateStamp}."/>

Do I put the [branch] and [status] in the buildnumber call, maybe?

Shawn Castrianni
CM Lead Architect
Halliburton Drilling, Evaluation and Digital Solutions Building 2
2101 City West Blvd.
Houston, TX  77042
Work:  713-839-3086
Cell:  832-654-0888
Fax:  713-839-2758

-----Original Message-----
From: Xavier Hanin []
Sent: Wednesday, February 06, 2008 1:49 AM
Subject: Re: cache problems

On Feb 6, 2008 8:25 AM, Shawn Castrianni <>

> How important is the cache?  All of my work is within my corporate
> intranet so everything is pretty fast.  The reason I ask is that the cache
> seems to cause me headache.  I am testing different scenarios and features
> of ivy with test build.xml and ivy.xml files.  When I think my ivy file
> should fail in finding a module during retrieve, it succeeds because it
> found the wrong one in the cache.  If I delete my cache and then rerun my
> test, it fails as I expect.  That makes me think that when I deploy my ivy
> implementation, my users will sometimes be picking up the wrong dependencies
> because of stuff in the cache.  Am I doing something wrong?  I am thinking I
> should do a cleancache before every ivy task to make sure it is clean for
> each of my ivy tasks.  Can I just turn off the usage of the cache?
>  Obviously, this is not the intended behavior of someone using ivy so I must
> be missing something.

Ivy 2 cache management has been highly improved, but you can't disable the
cache completely, since all post resolve tasks rely on file only, so resolve
need to ensure that all your dependencies are available as files. If you're
working with a fast enough shared file system, you can just set
useOrigin="true" on your cache settings, and you'll almost disable the cache
(we still have some issues to fix with the new cache implementation, but it
should already work pretty fine). If you use ofther kind of resolvers (http,
...) then Ivy we'll need to download files in the cache. So what you can do
is either clean your cache before each run, or set checkModified="true" and
changingPattern="*" to make sure Ivy will always look at your repository.

On the other hand, I still think having unique revisions is a good practice,
and if you follow this principle you won't ever have any problem with the

> My module revision numbers are not globally unique.  I could have a
> revision 080205.00 for module A branch 1 and a revision 080205.00 for
> module A branch 2.  If the cache is just looking at the revision numbers
> assuming they are globally unique, then it could sometimes get the wrong
> branch version since the revision numbers are the same.  Is this a bug in
> the cache or do I need to make my revision numbers globally unique by adding
> the branch name somehow?

Antoine has just raised an issue about the exact same problem which still
needs to be better qualified. As Maarten suggests in the issue, the cause
may only be that Ivy doesn't currently use the branch token in the default
cache patterns. This can easily be fixed, I suggest trying it out.


> ---
> Shawn Castrianni
> Landmark
> Halliburton Drilling, Evaluation and Digital Solutions
> Building 2
> 2101 City West Blvd.
> Houston, TX  77042
> Work:  713-839-3086
> Cell:  832-654-0888
> Fax:  713-839-2758
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly prohibited.
>  If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.

Xavier Hanin - Independent Java Consultant

View raw message