commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Commons Wiki] Update of "MavenGroupIDChange" by sebbapache
Date Sat, 13 Nov 2010 14:32:17 GMT
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 sebbapache.
http://wiki.apache.org/commons/MavenGroupIDChange?action=diff&rev1=3&rev2=4

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

  === 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)?
+ There are two possible scenarios here
+ * The new version of the code is binary incompatible with the old version.
+ * The new version is binary compatible with the old version.
  
+ 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 incompatible 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 much.  This approach solves the "jar hell" issue) (Sebb: there
is no "jar hell" if the versions are binary compatible)?
+ 
+ For binary-compatible releases, the Java package name should NOT be changed, as that causes
unnecessary work for all users.
+ It follows that the Maven groupID should not be changed either, unless relocation POMs are
guaranteed to work.
+ 
+ As a concrete example, Logging uses the groupId commons-logging. Changing the package name
merely to allow the groupId to be changed would cause an awful lot of work, for almost no
benefit.
+ 

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


Mime
View raw message