committed in r1424835. Please note that weaver alone has 11 modules so far. And it's likely to become more...
LieGrue, strub ----- Original Message ----- > From: Mark Struberg <strub...@yahoo.de> > To: Commons Developers List <dev@commons.apache.org> > Cc: > Sent: Friday, December 21, 2012 10:43 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... > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
