ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Crahen" <eric.crahen.li...@gmail.com>
Subject Re: Opt out of the cache for a resolver
Date Sun, 24 Dec 2006 14:44:38 GMT
When I use the copy in my override repository its the patched version.
When I remove the copy in my override repository it is the released version.

This is the point of a local override repository.
There are plenty of valid reasons for this:

For one, schedules do not always line up. I may need to continue with
development efforts in parallel with some other group. Having a mechanism to
allow me to use a work around while someone else integrates an offical patch
for a bug. My development isn't on hold while an external group who is not
on the same schedule works things out.

Another is simply to test/explore. I may have several librariess I own. A
depends on B
depends on C. I may need to modify a private copy of B temporarily to add
additional logging, or enable an MBean, switch a connection pool
implementation
from one thing to another. Maybe I'm simply doing this as an exercise to
understand
how some code works.

In neither of cases do I plan on doing a release, and in neither does it
make sense
to play games with version numbers. In the first, I can't predict what
version number
the official fix for a bug will be in - will it be commons-http-1.1.1 or
commons-http-1.2?
I don't know, and its not up to me. Probably depends what other bug fixes or
enhancements
they decide to release.

In the second I have no reason to bump the version. I'm not making a
release, I'm debugging.
I might have inherited this dependency transitively and I don't want to go
tracking down the
libraries I depend on that depend on libraries, that depend on libraries
that depend on
this one library I want to add some trace to. Its a waste of time. All I
want to do is better
understand how something works - and I know the version of the thing I'm
trying to understand,
I just want to modify it locally. Having to change version/revisions for
this can, in the case of
dependencies inherited transitively, mean chasing down dependencies editing
the ivy.xml's to
depend on ${bumped_version}, and publishing those into my local override as
well. That's
a lot of extra steps when I know I just want to add some debugging code to a
very specific
package version.

There are other use cases that revolve around working on multiple libraries
at once. LibraryA
my depend on LibraryB. They are both mine, and I am working bugs that
involve changes to both.
I may have multiple bugs to work on in different copies one in ~/bugfix1 and
one in ~/bugfix2. Again,
I don't care to bump version numbers. Perhaps a code review won't be
conducted until the end of
the week, and its part of a process that happens after that review where the
appropriate versions
are decided. I really don't care about playing guessing games with version
numbers. I know the
library versions that cause a bad behavior and my job right now is to find
out what is wrong, and
propose a solution.


Having a way to override a library for these reasons is not shooting myself
in the foot. What I've
described is very useful. I'm shooting myself in the foot by not enabling
this sort of behavior.


On 12/24/06, Stephane Bailliez <sbailliez@gmail.com> wrote:
>
> Eric Crahen wrote:
> >
> > The use case for this is that I want to do something, like override
> > commons-http client locally to work
> > with a bugfix that hasn't been released yet. I use a chain with a local
> > filesystem resolver in the front
> > so that returnFirst="true". This way whatever I put in my local
> > resolve will
> > effectively override the
> > offical release. Now at some point I don't need the override - maybe the
> > bugfix is integrated into the
> > offical release - maybe I just decide that bug is not relevant to me
> > anymore
> > and I want to go back to
> > building against the offical copy. I want to just remove the local
> > override
> > by removing that artifact and
> > ivy file from my local filesystem. This fails because the cache is never
> > invalidated correctly.
> So you will end up with commons-http-1.1.jar and commons-http-1.1.jar ?
> which one is the genuine 1.1 ? the first one or the second one ?
>
> Don't do that. It is a crazy idea to hack the jar and silently swap it
> while keeping the same version.
> You are just shooting yourself in the foot by doing that.
>
> -- stephane
>
>


-- 

- Eric

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