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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
