"Buy I want to use *my* version!"

[John Williams <jr...@pobox.com>]

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

Re: "Buy I want to use *my* version!"

[Eric Crahen <er...@gmail.com>]

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 <jr...@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