ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Gill" <>
Subject Re: Opt out of the cache for a resolver
Date Sun, 24 Dec 2006 14:55:37 GMT
My view of the world is that a version is a version, and if you release
something, then it is released forever, and every package that is release
should be uniquely identifyable. So you need to given your hacked/debug
releases a unique version number (or maybe a different name like
Erics-hacked-commons-http version 1.1 :-) That way, when you don't want your
team to use Erics-hacked-commons-http version 1.1 anymore, they simply go
back to using commons-http version 1.1.1 or 1.2 or whatever it finally gets
released as. This way, you won't have to clean out your cache.

On 12/24/06, Eric Crahen <> wrote:
> 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 <> 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

John Gill

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