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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Sent: vrijdag 2 februari 2007 3:14
To: [email protected]
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 <[EMAIL PROTECTED]> 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
