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:59:44 GMT
Good post Eric!

I share your feeling (and John one too) about this problem. It should be
much easier for the developer to use a local version, without having to find
a workaround as you explain. So I think it's one more argument for a better
cache management in Ivy. So, you guys can vote for IVY-399 if you haven't
already, to show that it really address a community need!

- Xavier

On 2/2/07, Eric Crahen <eric.crahen.lists@gmail.com> wrote:
>
> In my experience the process usually goes like this. I think this is close
> to what
> John's situation is as well.
>
> I have a resolver chain that goes local -> remote
>
> I'm working on a project, AvX
>
> I check out the current revision so in my filesystem I have the source
> and an ivy.xml that says vX.
>
> I work for a bit, a few compiles are performed, ivy had to cache things to
> do this. So my cache now contains BvY and CvZ.
>
> I discover a bug, which I think has something to do with C. So I check out
> the source for the version of CvZ. I make a change and compile this
> project,
> publishing the artifacts to my local resolver.
>
> Note, that I never once changed anything in an ivy.xml, no versions have
> changed.
>
> Now I move back to project A. I think that by making the change I made in
> CvZ
> I have fixed my problem, so I need to compile and test A.
>
> Here's the problem and why its related to the cache. When I build A, ivy
> resolves
> the dependencies and it just pulls out the CvZ it had in the cache. This
> is
> the wrong
> artifact. The version in the cache was pulled down from the remote
> repository from
> previous work Ivy did. So even though I've made my local change, and I've
> published
> it, it doesn't get seen by ivy. This is because of the nature of the
> caching
> mechanism
> in ivy.
>
> ---
>
> I either have to blow away the cache manually, which no one should have to
> ever do.
>
> or
>
> I have to change versions of the things I'm working on in order to
> invalidate the cache.
>
> ---
>
> Let's say I do either one of these, even though neither is preferable.
>
> I find that I didn't fix the bug. I need to make another change to CvZ
> since
> I didn't get it
> right. I go back to that workspace, change, compile, publish. I go back to
> project A and
> build - but wait, my change isn't picked up? Why? The cache again.
>
> ---
>
> One reason that people I work with, myself included, do not want to bump
> version numbers
> for local development. I will have many iterations, I may just be testing
> code - I've not gone through
> a QA process, there is no new version associated with what I am working on
> logically. I'm not
> talking about ivy's concept of version. I'm talking about a human being
> developer working on something
> that is not quite done, and not certain to see the light of day - that's
> not
> a new version to people, thats
> a local change to an existing version. People don't want to accept that
> work
> in progress not known
> to be in a good state must be associated with a version number and
> crystallized in ivy, it just is not
> intuitive or sensible in some development styles. It might be fine for
> some,
> but its not for others. Like John
> said, people just want it to "work"
>
> Another reason is that if I do change version numbers for C, now I have to
> check out B and bump it as well
> so that it depends on the new version of C. I'm not even making changes to
> B, but I have to change the version
> so that my translative closure of dependencies will pick up my new version
> of C (which I don't even know is any good yet).
> Then I get to bump A to depend on the new B. So I just created three new
> versions and touched one package I haven't
> even altered code in just to test a change in 1 downstream package. That
> is
> a lot of hoops to jump through, and people
> rightly aren't thrilled about doing it.
>
>
>
> 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.
> > 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)
> >
> > 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).
> >
> > 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
> > >
> > >
> >
> >
>
>
> --
>
> - Eric
>

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