This stuff isn't just all about Maven. The artifactId change is, but the package name change is useful (and even required) in non-maven environments, too.
On Sat, Nov 13, 2010 at 10:09 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > This is a great post. Personally, I think the need to do this is completely > caused by Maven and I've been discussing this with them for years. I will be > writing up a proposal on the Maven wiki which would eliminate the need to > keep renaming packages and artifacts. Instead, artifacts would contain > additional metadata they could use to describe things like the version(s) of > the API that they support, configuration versions, and other attributes that > might affect the user of the artifact. Then users of the artifact, in > addition to specifying the groupId and artifactId would specify the > attributes and their versions that they require. Maven could then use this > information to insure that only a single version of the artifact is present > and that it meets the requirements of all the projects that list it as a > dependency. If multiple projects specify the artifact with different > metadata that can't be resolved by any available version of the artifact then > the build would fail. > > Ralph > > On Nov 13, 2010, at 6:32 AM, Apache Wiki wrote: > >> 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 >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
