ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject RE: "Buy I want to use *my* version!"
Date Fri, 02 Feb 2007 07:51:45 GMT
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
View raw message