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:19:19 GMT
I don't see how the use-case of needing to use a work around while
an official patch is integrated to a package can be so easily discounted
as not valid.

Can you walk me through how I would do what you are proposing. Maybe you
have a better way to do this.

I'll change the names to protect the innocent.

I'm working on my library A, library A depends on B, library B depends C,
library C depends on D. library D depends on external A. external X depends
on
external Y.

Here is the picture form of the dependency.

A -> B -> C -> D -> X -> Y

I've inherited Y as a transitive dependency by depending on X. Both are
librariess
I do not own, and I do not have influence over the version numbers they use,
or will
use when releases are made to these libraries.

I've found that there is a bug in Y.

Several things need to happen for me at this point:

#1.

I need to keep working on A. So I need to be able to patch Y.

This means I need a local copy. Now you can label this Eric's-hacked-library

if you want. I really don't think that's a fair characterization. My intent
is to repair
the bug, and submit a patch and bug report with repro steps to the owner of
library Y.

- I need to be able to build Y locally so I can unit test Y and put the fix
together.

#2

- I need to be able to build any of my libraries against the bugfix Y in
order
to run integration tests.

The bugfix does not involve a signature change, it is binary compatible.
There is no need to recompile all the libraries, but I would like to run
integration
tests on any of A,B,C or D that I choose to. Integration tests are part of
my
build - they run after unit tests.

#3

When the bugfix I submitted is accepted, or the bug is corrected by someone
else's patch,

- I need to stop using the local bugfix version and switch back to the
current
official version.


Now in this real scenario, I don't need to make any releases of my own
libraries
for others to consume. All I need to do is unblock my progress by patching a
bug
in someone elses code. I don't want to wait and not accomplish anything for
an
unknown amount of time while an external party repairs thier code. Because
I'm
a good citizen I will report the bug and give them a fix. Ultimately, the
goal here
is that I need to keep working while the bug gets sorted out.

Can you explain how I would do this. Please walk me through very
specifically
what you are suggesting I change in the ivy.xml's. Where I publish these
changes
to. And how I remove the changes when the bug is fixed.

The three things I listed must happen. This is a requirement.

I want to do it without manually removing a thing from the cache, but since
that
cache issue really is secondary in what we are talking about now, you can
ignore
that request for the time being. (But I'll probably come back to it later)


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