commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <brunodepau...@yahoo.com.br>
Subject Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml
Date Tue, 12 Feb 2013 20:36:15 GMT
> 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),
thus having the groupId explicit in the other children modules can help developers/users (and
maybe avoid errors) :o)

Fair point. I'll revert the change today then.

Thanks!

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


----- Original Message -----
> From: sebb <sebbaz@gmail.com>
> To: Commons Developers List <dev@commons.apache.org>; gudnabrsam@gmail.com
> Cc: Bruno P. Kinoshita <kinow@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 <gudnabrsam@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 
> <kinow@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 <sebbaz@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,  <kinow@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-unsubscribe@commons.apache.org
>>>  >For additional commands, e-mail: dev-help@commons.apache.org
>>>  >
>>>  >
>>>  >
>>>  >
>>> 
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>  For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message