On 12 February 2013 20:36, Bruno P. Kinoshita <brunodepau...@yahoo.com.br> wrote: >> But the groupId varies between components, so I think it's important >> to be specific, even if it happens to be the same as the parent. > > > Ah, I think I got it. The build-tools child module has a different groupId > (it's org.apache.commons:commons-functor-build-tools)
No, the build tools groupId is defined as follows: <groupId>org.apache.commons</groupId> > , thus having the groupId explicit in the other children modules can help > developers/users (and maybe avoid errors) :o) No, that was not my intention. > Fair point. I'll revert the change today then. > > Thanks! > > Bruno P. Kinoshita > http://kinoshita.eti.br > http://tupilabs.com > > > ----- Original Message ----- >> From: sebb <seb...@gmail.com> >> To: Commons Developers List <dev@commons.apache.org>; gudnabr...@gmail.com >> Cc: Bruno P. Kinoshita <ki...@apache.org> >> Sent: Tuesday, February 12, 2013 6:20 PM >> Subject: Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml >> >> On 12 February 2013 07:05, Matt Benson <gudnabr...@gmail.com> wrote: >>> Personally I fall on the side of inheriting as much as possible from parent >>> POMs. If necessary we can have a Commons-wide vote. >> >> Yes, for items that are common to all components we should inherit. >> >> But the groupId varies between components, so I think it's important >> to be specific, even if it happens to be the same as the parent. >> >> Otherwise it is not clear if the inheritance is deliberate or accidental. >> >>> Matt >>> >>> >>> On Mon, Feb 11, 2013 at 10:26 PM, Bruno P. Kinoshita >> <ki...@apache.org>wrote: >>> >>>> >Although strictly speaking the groupId is not required as it is >>>> >inherited from the parent groupId, I think it's best to be >> explicit. >>>> >>>> I'm fine with or without the groupId in the child project. I think >> it's >>>> useful to avoid misspellings and removed because of an Eclipse warning. >> But >>>> if by being explicit we will help users/developers, then I'm +1 for >>>> repeating the groupId :-) Should I revert this change then? (and >> perhaps >>>> this could be a good practice for multi-module commons components >> too?). >>>> >>>> Thanks >>>> >>>> [1] https://git-wip-us.apache.org/repos/asf/maven.git >>>> >>>> Bruno P. Kinoshita >>>> http://kinoshita.eti.br >>>> http://tupilabs.com >>>> >>>> >>>> >________________________________ >>>> > From: sebb <seb...@gmail.com> >>>> >To: dev@commons.apache.org >>>> >Sent: Tuesday, February 12, 2013 12:39 AM >>>> >Subject: Re: svn commit: r1445005 - >>>> /commons/proper/functor/trunk/api/pom.xml >>>> > >>>> >On 12 February 2013 00:47, <ki...@apache.org> wrote: >>>> >> Author: kinow >>>> >> Date: Tue Feb 12 00:47:23 2013 >>>> >> New Revision: 1445005 >>>> >> >>>> >> URL: http://svn.apache.org/r1445005 >>>> >> Log: >>>> >> Remove duplicated groupId >>>> >> >>>> >> Modified: >>>> >> commons/proper/functor/trunk/api/pom.xml >>>> >> >>>> >> Modified: commons/proper/functor/trunk/api/pom.xml >>>> >> URL: >>>> >> http://svn.apache.org/viewvc/commons/proper/functor/trunk/api/pom.xml?rev=1445005&r1=1445004&r2=1445005&view=diff >>>> >> >>>> >> ============================================================================== >>>> >> --- commons/proper/functor/trunk/api/pom.xml (original) >>>> >> +++ commons/proper/functor/trunk/api/pom.xml Tue Feb 12 >> 00:47:23 2013 >>>> >> @@ -22,7 +22,6 @@ >>>> >> >> <artifactId>commons-functor-parent</artifactId> >>>> >> <version>1.0-SNAPSHOT</version> >>>> >> </parent> >>>> >> - <groupId>org.apache.commons</groupId> >>>> > >>>> >Although strictly speaking the groupId is not required as it is >>>> >inherited from the parent groupId, I think it's best to be >> explicit. >>>> > >>>> >> <artifactId>commons-functor-api</artifactId> >>>> >> <name>Commons Functor API</name> >>>> >> <description>Provide the basic >> APIs</description> >>>> >> >>>> >> >>>> > >>>> >>> --------------------------------------------------------------------- >>>> >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 >> > > --------------------------------------------------------------------- > 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
