ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: "Buy I want to use *my* version!"
Date Fri, 02 Feb 2007 08:01:05 GMT
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 <gscokart@gmail.com> 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 [mailto:eric.crahen.lists@gmail.com]
> Sent: vrijdag 2 februari 2007 3:14
> To: ivy-user@incubator.apache.org
> 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 https://issues.apache.org/jira/browse/IVY-399, 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 <jrw@pobox.com> 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
>
>

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