Page History

...

If the change from commons-foo:commons-foo to org.apache.commons:commons-foo is accompanied by a change to the Java package name, e.g. to org.apache.commons.foo3, then there will be no classpath issue, as both Maven and Java treat the artifacts as different.

There are two possible scenarios here

• The new version of the code is binary incompatible with the old version.
• The new version is binary compatible with the old version.
  

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 incompatible 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 mcuhmuch. This approach solves the "jar hell" issue) (Sebb: there is no "jar hell" if the versions are binary compatible)?

For binary-compatible releases, the Java package name should NOT be changed, as that causes unnecessary work for all users. It follows that the Maven groupID should not be changed either, unless relocation POMs are guaranteed to work.

As a concrete example, Logging uses the groupId commons-logging. Changing the package name merely to allow the groupId to be changed would cause an awful lot of work, for almost no benefit.