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 10:22:00 GMT
On 2/2/07, Gilles Scokart <gscokart@gmail.com> wrote:
>
> Now I understand the link with the cache.  What should be solved is that :
> 1. We should have a chain : <local/> , <cache><share/></cache>.
(IVY-399)
> 2. The local resolver must be able to force a given revision of a module.
> (Something else that might also have a big impact on the design).
>
> Maybe using nested resolvers might help to solve the second point.
> Having the share resolver inside the local instead of after
> (<local><cache><share></cache></local>)


In other words making any resolver able to behave also as a chain (which is
a container of other resolvers). Why not, even if I'm not sure to see how it
solves the second point.

With this kind of structure, local can be implement so that it hides any
> other revision than the one in local if there is.  But still, ivy should
> accept to replace C vY by a C vLocal.  And I don't know what is the impact
> for that.


I'm not sure of the impact, but Ivy is already used to get revision which
are not the one asked, when what you ask is a dynamic version (you ask 1+
and you get 1.3 for instance). So it shouldn't be too difficult to address.

- Xavier

PS: Yes, I mixed my alphabet.  It was A and not C.  Sorry
>
> Gilles
>
>
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: vendredi 2 février 2007 9:41
> To: ivy-user@incubator.apache.org
> Subject: Re: "Buy I want to use *my* version!"
>
> On 2/2/07, Gilles Scokart <gscokart@gmail.com> 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.
>
>
> I think you're talking about A here, no?
>
> 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)
>
>
> The local resolver will check the cache to avoid doing a search if the
> module is already in the cache, will find the cached version of C vY, and
> will return it. [1] And this is the problem, other wise it could decide to
> return what is found in the local repository whatever the version asked
> was.
> You can do that easily if you use patterns without revision when you setup
> your local resolver. Note that now that I think more about it, it may a
> problem to return a revision which doesn't match at all the asked
> revision,
> so maybe this is also something we should be tested and maybe improved:
> put
> enough trust in the dependency resolver.
>
> 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).
>
>
> Yes you're right, that's why you usually use returnFirst on your local
> resolver in your chain, to avoid finding a revision which is actually
> newer.
> But the notion of latest is configurable in Ivy (and you did configure it
> with your special meanings), so we can say that a local revision is always
> considered newer as any other revision, and is thus always the latest.
>
> - Xavier
> [1] see this piece of code in BasicResolver.getDependency:
>          if (!isDynamic && !isCheckmodified() && !isChangingDependency)
{
>             cachedRmr = findModuleInCache(data, mrid);
>             checkedCache = true;
>             if (cachedRmr != null) {
>                 if (cachedRmr.getDescriptor().isDefault() &&
> cachedRmr.getResolver() != this) {
>                     Message.verbose("\t"+getName()+": found revision in
> cache: "+mrid+" (resolved by "+cachedRmr.getResolver().getName()+"): but
> it's a default one, maybe we can find a better one");
>                 } else {
>                     Message.verbose("\t"+getName()+": revision in cache:
> "+mrid);
>                     return toSystem(cachedRmr);
>                 }
>             }
>         }
>
>
> Gilles
> >
> >
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: vendredi 2 février 2007 9:01
> > To: ivy-user@incubator.apache.org
> > 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 <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