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 15:58:52 GMT
Also to go back to a package being forever released as a side thread.

I may have many small releases of libraries within my organization. The
reality is these packages have a lifetime and will be deprecated. They may
exist forever, but I will not support them forever. I mark classes in
deprecated
versions @Deprecated to warn those who still depend on them they are on
their own.

I want to just re-release this package version with those annotations to do
this
I can do that via the overwrite property on release quite easily.

What I can't do is invalidate peoples caches. I already have a very fast
network, or a replicated shared filesystem, so I am willing to accept the
cost
of doing a checksum to invalidate my cache or not. Consistency is important
for my use case, and I really don't see a strong reason not to enable such
behavior. This need not be the default behavior, but would be available to
those who need it. Those who don't care to deprecate package are unaffected.


On 12/24/06, John Gill <llignhoj@gmail.com> wrote:
>
> 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 <eric.crahen.lists@gmail.com> 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 <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
> >
> >
>
>
> --
> Regards,
> John Gill
>
>


-- 

- Eric

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