Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of simone.tripodi@gmail.com
 designates 74.125.82.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=BDnieAzAxE1rbGoMysSVZtLNudmI+GeSojyKYMPnm5+ZDu0x2Xmuk//AUCPCNvBm/n
         ARWAQasZOi5g0Mmg6R25KfIrBRh9hHoGtluq1iEmdi53AKJ15Ud0gTj+mU60nuzyF3Wc
         mJQVW07o39FKsQjhEwBmqWCeUTfGpV0z6TkZc=
MIME-Version: 1.0
Sender: simone.tripodi@gmail.com
In-Reply-To: <imetp9$n9a$1@dough.gmane.org>
References: <20110323220908.47D6A238899C@eris.apache.org>
	<AANLkTi=hZ2SEwSxdGrKXgL+erenqgQsk3tKkVLm61nU9@mail.gmail.com>
	<AANLkTimeoaFSzG0T4ESQPBFH=+-wWQRt19S9Z7jsoUQ-@mail.gmail.com>
	<AANLkTikq+_1=SPOD0WPx42J0JVtSGbC71TVp1WGJR7mD@mail.gmail.com>
	<AANLkTikekifr4nw+sao=w+HNqssZ7RfVNJ9fiD2XfopY@mail.gmail.com>
	<AANLkTikf8sYUTsbneSV4S4a68X7jKaO6kWOpyX9cmn5=@mail.gmail.com>
	<AANLkTimZoh1WHLK6zgDhVyxmTXEt6ZKVv+swiLfDi6RK@mail.gmail.com>
	<AANLkTin-7+QOG4AXhKppRiGe-jyDmpQKPd1RMyd5uBb_@mail.gmail.com>
	<imetp9$n9a$1@dough.gmane.org>
Date: Thu, 24 Mar 2011 10:42:14 +0100
Message-ID: <AANLkTiks_f-dko9m0tKdGZviqotYmrRD1cgEKGgyRZ_Q@mail.gmail.com>
Subject: Re: svn commit: r1084776 - /commons/proper/pool/trunk/pom.xml
From: Simone Tripodi <simonetripodi@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Jorg,
I agree with you, but I think we've enough flexibility that if the
component needs to override the groupId, simply redeclare it.

BTW If we're changing the parent reference, maybe we need to to review
the whole set of metadata, I won't expect that a component is released
with overlooked groupId, do you?
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/


On Thu, Mar 24, 2011 at 9:01 AM, J=C3=B6rg Schaible
<joerg.schaible@scalaris.com> wrote:
> sebb wrote:
>
>> On 24 March 2011 00:09, Niall Pemberton <niall.pemberton@gmail.com> wrot=
e:
>>> On Thu, Mar 24, 2011 at 12:05 AM, sebb <sebbaz@gmail.com> wrote:
>>>> On 23 March 2011 23:37, Simone Tripodi <simonetripodi@apache.org> wrot=
e:
>>>>> On Thu, Mar 24, 2011 at 12:28 AM, sebb <sebbaz@gmail.com> wrote:
>>>>>> On 23 March 2011 23:14, Simone Tripodi <simonetripodi@apache.org>
>>>>>> wrote:
>>>>>>> I think maven best practice would suggest to avoid groupId
>>>>>>> duplication - for pool2 we agreed to switch to o.a.c groupId.
>>>>>>> which problems are you speaking about? I'm asking because I would
>>>>>>> have missed something I don't know yet.
>>>>>>
>>>>>> I just mean that the POM should specify the groupId even if it is th=
e
>>>>>> same as the parent.
>>>>>>
>>>>>
>>>>> I still don't understand the reason why it should do it, can you poin=
t
>>>>> me to some doc?
>>>>
>>>> AFAIK, there is no such document.
>>>>
>>>> But it's important for people reading the POM to know immediately what
>>>> the groupId is, without having to go searching for the parent.
>>>
>>> There is no need to go searching for the parent. You can just look at
>>> the <parent> element's groupId in the POM you're reading.
>>
>> OK, but I still think it's risky to rely on inheritance for such an
>> important value.
>>
>> In theory, the parent might be changed, e.g. to the Apache POM, as
>> used in Common Site
>>
>> Also, having an explicit value documents that the groupId is being
>> intentionally set for this component.
>
> The info is redundant, but I second Sebb here, simply because in Commons =
not
> every component has necessarily the same groupId. Currently we switch fro=
m
> the old M1-style groupId to this one only on purpose and therefore I pref=
er
> also the explicit definition here.
>
> - J=C3=B6rg
>
>
> ---------------------------------------------------------------------
> 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