You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Changing Maven Group Id

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

Several Commons components are using Maven Group Ids other than org.apache.commons. This makes more work for Nexus and Maven Central maintenance.

This page is intended to collect together information on the issues to consider when changing a Maven Group Id.

Examples that follow assume that the Commons component Foo currently uses groupId=commons-foo and artifactId=commons-foo, i.e. commons-foo:commons-foo for short. The classes are currently in the org.apache.commons.foo Java package hierarchy.

Assume also that there is a Bar application which depends on two libraries, lib1 and lib2. lib1 depends on commons-foo:commons-foo:1 and lib2 depends on commons-foo:commons-foo:2.

Maven dependency resolution

Maven assumes that artifacts with the same GroupId and ArtifactId represent the same item, and ensures that only one instance of each such artifact is added to the classpath.

In the above example, only commons-foo:commons-foo:2 would be added to the classpath.

If the groupId is changed, then org.apache.commons:commons-foo will be treated as a different artifact, and the Maven classpath could potentially contain two copies of the same component.

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.

This sounds ideal, but the relocation POMs may not always be processed??

TBA details of relocation poms

Change of package name

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.

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?

  • No labels