ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Crahen" <>
Subject Re: "Buy I want to use *my* version!"
Date Fri, 02 Feb 2007 08:50:50 GMT
In my experience the process usually goes like this. I think this is close
to what
John's situation is as well.

I have a resolver chain that goes local -> remote

I'm working on a project, AvX

I check out the current revision so in my filesystem I have the source
and an ivy.xml that says vX.

I work for a bit, a few compiles are performed, ivy had to cache things to
do this. So my cache now contains BvY and CvZ.

I discover a bug, which I think has something to do with C. So I check out
the source for the version of CvZ. I make a change and compile this project,
publishing the artifacts to my local resolver.

Note, that I never once changed anything in an ivy.xml, no versions have

Now I move back to project A. I think that by making the change I made in
I have fixed my problem, so I need to compile and test A.

Here's the problem and why its related to the cache. When I build A, ivy
the dependencies and it just pulls out the CvZ it had in the cache. This is
the wrong
artifact. The version in the cache was pulled down from the remote
repository from
previous work Ivy did. So even though I've made my local change, and I've
it, it doesn't get seen by ivy. This is because of the nature of the caching
in ivy.


I either have to blow away the cache manually, which no one should have to
ever do.


I have to change versions of the things I'm working on in order to
invalidate the cache.


Let's say I do either one of these, even though neither is preferable.

I find that I didn't fix the bug. I need to make another change to CvZ since
I didn't get it
right. I go back to that workspace, change, compile, publish. I go back to
project A and
build - but wait, my change isn't picked up? Why? The cache again.


One reason that people I work with, myself included, do not want to bump
version numbers
for local development. I will have many iterations, I may just be testing
code - I've not gone through
a QA process, there is no new version associated with what I am working on
logically. I'm not
talking about ivy's concept of version. I'm talking about a human being
developer working on something
that is not quite done, and not certain to see the light of day - that's not
a new version to people, thats
a local change to an existing version. People don't want to accept that work
in progress not known
to be in a good state must be associated with a version number and
crystallized in ivy, it just is not
intuitive or sensible in some development styles. It might be fine for some,
but its not for others. Like John
said, people just want it to "work"

Another reason is that if I do change version numbers for C, now I have to
check out B and bump it as well
so that it depends on the new version of C. I'm not even making changes to
B, but I have to change the version
so that my translative closure of dependencies will pick up my new version
of C (which I don't even know is any good yet).
Then I get to bump A to depend on the new B. So I just created three new
versions and touched one package I haven't
even altered code in just to test a change in 1 downstream package. That is
a lot of hoops to jump through, and people
rightly aren't thrilled about doing it.

On 2/2/07, Gilles Scokart <> wrote:
> Mmm, I think I missed something.
> What is wrong in my thinking:
> 1. When C is resolved, the share repository must be accessed to find B vX,
> and using a cache is not an issue.
> 2. If B vX depends on C vY, ivy will ask for C vY to the local resolver,
> and it will return nothing, so the share resolver will be used (if nothing
> is in the cache)
> Note also that the notion of latest is not applicable in that
> case.  Indeed,
> the local version can be older than the version on the share (for example
> when you are using a continuous build).
> Gilles
> -----Original Message-----
> From: Xavier Hanin []
> Sent: vendredi 2 février 2007 9:01
> To:
> Subject: Re: "Buy I want to use *my* version!"
> I think IVY-399 could help solve the problem, because it's really related
> to
> the cache. But note that even without IVY-399 there's a solution with a
> custom DependencyResolver (and not a repository), because the problem lies
> in the resolvers and their use of the cache.
> When Ivy resolves the module A dependencies, it finds that it depends on
> latest version of B. Then it finds B vX as the latest version of B, which
> depends on C vY (and not on the latest one, and here is the problem). Then
> Ivy ask the resolver to resolve C vY, the resolver see that there is a C
> vY
> in the cache, and returns it, without checking any repository. So if we
> were
> able to disable cache use for the dependency resolver used as a local one,
> we could return what is in the local repository, whatever the revision
> asked
> is. This is IVY-399 solution. The current solution is to hard code a
> resolver with no cache management, and this will have the same effect and
> I
> think that's what you're thinking about John.
> - Xavier
> On 2/2/07, Gilles Scokart <> wrote:
> >
> > I fear IVY-399 will not solve the problem.  If B is not in the local
> > repository, it will still depend on the old C whatever any caching.
> >
> > I also have similar issue, but I didn't yet manage to solve it.
> >
> > I solved a closed problem by using different version names in local
> > repository and in the share repository in such a way that the local
> > artefacts get the priority (even if they are older than the one on the
> > share
> > repository).  I did that by placing in the configuration file:
> >
> > <latest-strategies>
> >         <latest-revision name="local-revision">
> >                 <specialMeaning name="build" value="-1"/>
> >                 <specialMeaning name="dev" value="1"/>
> >                 <!-- Dev received the priority -->
> >         </latest-revision>
> > </latest-strategies>
> >
> >
> > But unfortunately it only solves the case where C is a direct dependency
> > of
> > A.
> >
> >
> > Gilles
> >
> >
> > -----Original Message-----
> > From: Eric Crahen []
> > Sent: vrijdag 2 februari 2007 3:14
> > To:
> > Subject: Re: "Buy I want to use *my* version!"
> >
> > I have exactly the same use case. The reason that the resolver chains
> > always
> > break down has to do with how Ivy's cache is implemented. The change
> > suggested here, would
> allow
> > this to be corrected. Once this is done, all you would need to do to use
> > your versions is resolver against a resolver chain with your local
> > repository at the head.
> >
> > I have not found any simple work around with the current revision of ivy
> >
> > On 2/1/07, John Williams <> wrote:
> > >
> > > One thing I've been hearing from my coworkers is that when they have a
> > > locally-published module, they always want to use the local version
> > > regardless of versions exist in other repositories.  I've tried
> > > various strategies like setting the default resolver to stop after the
> > > first match and forcing local modules have high revision numbers, but
> > > there seems to be no reliable way to *just* use the local version of a
> > > module.
> > >
> > > The problem always seems to manifest itself like this: I'm working on
> > > a module A, which depends on module B, and module B depends on module
> > > C, but A does not depend directly on C.  I have a local version of A
> > > (because I'm working on it), but I'm using shared versions of B and C.
> > > Now suppose I discover that a bug in C is causing A to break, so I
> > > make a bug fix and C and publish it.  Now I want to see if my bug fix
> > > in C also fixed A, so I resolve in A and I get.....the old version of
> > > C!  This happens because A only depends on C through B, so the
> > > resolver will only consider the version of C that B depends on.
> > >
> > > There are two workarounds to this situation--either make A depend
> > > directly on C, or publish a new version of B for the sole purpose of
> > > updating the version of C it depends on.  Unfortunately when my
> > > coworkers get into this situation, they just want their code to work
> > > without having to untangle any weird Ivy voodoo.
> > >
> > > I have an idea for a fix but I don't know if it would work.  What if
> > > there was a special file system repository (resolver? both?) type
> > > would always choose a version when one is available? So in my
> > > scenario, this new resolver would pick my fixed version of C even
> > > though it doesn't match the revision number that B wants.  Would that
> > > even work?
> > >
> > > --jw
> > >
> >
> >
> >
> > --
> >
> > - Eric
> >
> >


- Eric
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message