commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Commons Wiki] Update of "MavenGroupIDChange" by James Carman
Date Sat, 13 Nov 2010 14:17:16 GMT
On 13 November 2010 14:12, James Carman <james@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 <wikidiffs@apache.org>
> Date: Sat, Nov 13, 2010 at 9:07 AM
> Subject: [Commons Wiki] Update of "MavenGroupIDChange" by James Carman
> To: Apache Wiki <wikidiffs@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


Mime
View raw message