commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject Re: [collections] Generifying Collections
Date Thu, 26 Oct 2006 21:17:03 GMT
> > Well, easy ...then you don't upgrade ;)
> >
> > Sorry, but the fact that an upgrade is not always is as easy as
> > replacing a jar is not an argument (IMO) As long as there is an
> > upgrade path it's up to the user to walk that path or not. The
> > important thing though is to have such a path.
> This seems like a strange argument, since the "Don't Upgrade" path is
> valid for people who are running into conflicts from API changes as well
> (and there are probably a lot more people that won't run into these
> problems if the removals are mostly focused on deprecated components.)

Sorry, not sure I get what you are saying

If it's just your decision to upgrade a library you should not be moaning about
work. We are talking about a major API change! Don't expect that to be done
with a jar replacement.

If you have to upgrade because another library is depending on another version
that's another story ...and then comes the question whether that's easy or not.

> I understand that sometimes conflicts can be a bit round about, they
> upgrade to (or add) a new component of Y and it causes their
> commons-collections to get upgraded.  They still have the choice of not
> making this upgrade, or using that other component.  Or they have the
> choice of using JarJar or some other tool force package changes.  Or
> helping to fix the dependency if they are using some open source project.
> I think we want to make the common case as easy as possible, and
> changing the package names makes the common case a pain in the butt.

Your project depends on A and B. A depends on the old-style collections
while B already made the move and uses the new collections. Now what?
As it is an incompatible change the only thing is trying to push A to upgrade
its dependency. (or jarjar magic) THAT is what I call a PITA. While otherwise
they would be happily living next to each other and everyone is happy.

For sure we could provide some scripts or even eclipse refactoring scripts
if necessary/possible. Most likely you will only need to remove all imports and
ask eclipse to organize imports on your code base anyway. To me that sounds
easier than trying to squeeze (let's face it) a new API into the same package.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message