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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
