commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ modules/privi...
Date Fri, 21 Dec 2012 09:31:45 GMT
Hi Mark,

Mark Struberg wrote:

> Jörg, what about all older living projects which used to have own groups
> even, like commons-lang:commons-lang?

groupIds with pattern commons-XXX are legacy and we keep them only because 
the relocation stuff of Maven does not really work well and we don't want to 
harass our users as long as any newer release is binary compatible. However, 
for new components or as soon as a new binary incompatible version of an old 
one is to be released, we change the groupId always to org.commons.apache 
and this had been the case for *all* components until now.

> Could you point me to this boilerplate stuff you think off? Maybe we can
> improve this.

IIRC we derive the value for the groupId from our parent pom at various 
places and we had also manual tasks for infra for all our components with a 
groupId of commons-xxx and I am not sure if this applies to all groupIds 
that are unequal to org.apache.commons.

> I have no problem with moving the packages back, but I personally think
> this would á la long end up in confusing end users.

As said, we have with vfs2 and jci already other commons components that 
make a precedence for multiple artifacts of one component. We share 
org.apache.commons as common groupId and therefore I am against a silent 
change of naming policy here. Note, that I did not veto the commit, because 
I want to hear other opinions, but without a consensus among us committers, 
I'd veto any such release.


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

View raw message