On 25/08/2010 7:13 PM, Benson Margulies wrote:
Let me recap the pain scenario here:
Existing poms reference commons-net under the old group ID.
commons-net releases a new version under a new group ID.
Dependencies under the old group ID won't be seen as 'the same thing'
as the new group ID, so
a project that references the new group ID and has a dependency that
uses the old group ID gets both in the classpath, and probably
experiences chaos until repaired with exclusions.
Unless maven grew a feature whereby the new artifact could explicitly
declare itself a successor of the old one under the other name, this
is unavoidable. Either don't rename or live with this as an annoyance
to the users of the new version. Renaming packages might help, insofar
as the two versions might then coexist happily.
A way to deal with this is to do what we do at the application level and
use aggregate POMs to specify dependencies on third party software.
Once we shift to the new version with the new group id, we will have to
add an exclusion to each of our aggregation POMs to prevent third party
packages from pulling in the old group id.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
