Page History

...

So if a class is updated such that its API is no longer backwards-compatible, it's not possible to use both in the same classpath. The only solution is to change the class name, e.g. by changing its package name - or one could change just the classname.
 \[In both of these cases the code could be made compatible again by keeping the original code alongside the new. However, at some point the old code will probably need to be deleted, at which time the versions will be incompatible anyway.\]

...

This can cause a problem, for which there are several possible solutions - none of which are ideal: * use relocation POMs

...

* change the Foo package name

Relocation POMS

A relocation POM can be set up to redirect references from commons-foo:commons-foo to org.apache.commons:commons-foo. Both would be seen as being the same item, avoiding duplicates on the classpath.

...

However, the change of Java package name is neither binary nor source-compatible, and can require a lot of work for users of Commons Foo. This may be acceptable if the new version has major changes to the API, but not otherwise - why should users (who may not even use Maven) be forced to change their code just to upgrade to the latest version (James Carman: the user will thank us when they try to use a library that requires the older version, we shouldn't discount this too mcuh. This approach solves the "jar hell" issue)?