Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for 
change notification.

The "MavenGroupIDChange" page has been changed by James Carman.
The comment on this change is: Added a comment to the package name change 
section..
http://wiki.apache.org/commons/MavenGroupIDChange?action=diff&rev1=2&rev2=3

--------------------------------------------------

  = 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.
- 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.
- 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.
- 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.
  
  == Classpath considerations ==
+ The Java classpath can contain multiple versions of the same classname (in 
different jars or directories). However, at most one version of a given class 
can be loaded into a single class-loader.
  
+ 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.]
- The Java classpath can contain multiple versions of the same classname (in 
different jars or directories).
- However, at most one version of a given class can be loaded into a single 
class-loader.
  
+ If there are multiple versions of the same class on the classpath, there's no 
guarantee which version will be loaded,  so in general the classpath should 
only ever contain a single version of each class.
- 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.]
- 
- If there are multiple versions of the same class on the classpath, there's no 
guarantee which version will be loaded, 
- so in general the classpath should only ever contain a single version of each 
class.
  
  == 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.
- 
- 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.
- 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:
+ 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
- * 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.
- 
- 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 (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)?
- 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?
- 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to