maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Correcting a groupID
Date Thu, 26 Aug 2010 15:30:08 GMT
On Thu, Aug 26, 2010 at 8:41 AM, Stephen Connolly
<> wrote:
> Why not have commons-net:commons-net become an empty jar which has a
> dependency on org.apache.commons:net
> that way, anyone with the old GA coords will just have an empty jar on their
> classpath and the correct jar as well

i don't see it.

Component A is sitting out there with a dependency on c-n:c-n:1

Component B has a dependency on A and also on c-n:c-n:1

Sebb changes the group ID.

Now, A still depends on c-n:c-n:1
B depends on, and on A
And we've got two dueling versions in classpath.

It doesn't help to release a new version c-n:c-n:12, since A isn't
using a range, it's pointing at '1'.

Am I missing something?

> On 26 August 2010 00:13, 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.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message