You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Apache Wiki <wi...@apache.org> on 2010/11/13 15:07:57 UTC
[Commons Wiki] Update of "MavenGroupIDChange" by James Carman
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Commons Wiki] Update of "MavenGroupIDChange" by James Carman
Posted by sebb <se...@gmail.com>.
On 13 November 2010 14:12, James Carman <ja...@carmanconsulting.com> 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 <wi...@apache.org>
> Date: Sat, Nov 13, 2010 at 9:07 AM
> Subject: [Commons Wiki] Update of "MavenGroupIDChange" by James Carman
> To: Apache Wiki <wi...@apache.org>
>
>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Fwd: [Commons Wiki] Update of "MavenGroupIDChange" by James Carman
Posted by James Carman <ja...@carmanconsulting.com>.
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.
---------- Forwarded message ----------
From: Apache Wiki <wi...@apache.org>
Date: Sat, Nov 13, 2010 at 9:07 AM
Subject: [Commons Wiki] Update of "MavenGroupIDChange" by James Carman
To: Apache Wiki <wi...@apache.org>
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org