No worries Jörg, I was just not aware of those additional steps/scripts. From a pure maven perspective I would prefer separate groupIds but I get your arguments regarding the other tooling.
Thanks for pointing me to this background! I will change the groupIds back to o.a.c. LieGrue, strub ----- Original Message ----- > From: Jörg Schaible <joerg.schai...@scalaris.com> > To: dev@commons.apache.org > Cc: > Sent: Friday, December 21, 2012 10:31 AM > 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... > > 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. > > Cheers, > Jörg > > > --------------------------------------------------------------------- > 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
