On 13 November 2010 14:12, James Carman <[email protected]> wrote: > I don't know why this showed up with so many diffs. All I did was > fire up the GUI version of the editor and add the comment in > parentheses. Sorry for the noise.
Must be a bug in the GUI editor. It looks like it has joined all the lines together. > > ---------- Forwarded message ---------- > From: Apache Wiki <[email protected]> > Date: Sat, Nov 13, 2010 at 9:07 AM > Subject: [Commons Wiki] Update of "MavenGroupIDChange" by James Carman > To: Apache Wiki <[email protected]> > > > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
