commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] time to move groupId?
Date Sat, 16 Oct 2010 14:41:55 GMT
On 16 October 2010 15:25, James Carman <james@carmanconsulting.com> wrote:
> Well at the time, we were under the impression that maven oils only allow
> one copy of the group:artifact on the classpath.  Has that changed?

No, but if one changes groupId, then there is no need to change
artifactId as well.

> On Oct 16, 2010 10:21 AM, "Phil Steitz" <phil.steitz@gmail.com> wrote:
>> On 10/16/10 10:03 AM, James Carman wrote:
>>> We have come up with a game plan that allows multiple versions of our
>>> libraries to be on the classpath at the same time (changing artifact and
>>> package name). Lang is doing things according to that plan and we hope
>>> others will follow suit. We had this discussion long ago and we don't
> need
>>> to rehash it now.
>>
>> I don't understand exactly what changing the artifactId accomplishes
>> beyond what changing the package name does. Can someone explain?
>> IIUC what Dennis is saying, just bumping the version will allow
>> multiple versions to be on the classpath at the same time and
>> changing the package name will avoid conflicts. What more are we
>> looking to accomplish by changing the artifactId?
>>
>> Phil
>>> On Oct 16, 2010 9:56 AM, "Dennis Lundberg"<dennisl@apache.org> wrote:
>>>> When you say consistent, what are you referring to? The fact that lang
>>>> has done it once?
>>>>
>>>> It is not the Maven way to change the artifactId when a new major
>>>> version comes out. And since we are talking about the Maven
>>>> "coordinates" (groupId, artifactId, version) I think it is best to
>>>> follow the standard Maven way of doing it.
>>>>
>>>> On 2010-10-16 00:28, James Carman wrote:
>>>>> I didn't say it was required. I said it was a good idea, because it
>>>>> would keep things consistent.
>>>>>
>>>>> On Fri, Oct 15, 2010 at 5:39 PM, Dennis Lundberg<dennisl@apache.org>
>>> wrote:
>>>>>> Changing the artifactId is not necessary. At least if we predict
that
> we
>>>>>> will not change the groupId again. In Maven the combination of
> groupId,
>>>>>> artifactId and version is unique. So
> org.apache.commons:commons-pool:2.0
>>>>>> and org.apache.commons:commons-pool:3.0 are two unique artifacts.
>>>>>>
>>>>>> On 2010-10-15 20:43, James Carman wrote:
>>>>>>> If we do change the package name to pool2, then I'd suggest the
>>>>>>> artifact id change too so that everything stays consistent. So,
the
>>>>>>> new artifact id would be commons-pool2 rather than commons-pool.
>>>>>>>
>>>>>>> On Fri, Oct 15, 2010 at 2:40 PM, James Carman
>>>>>>> <james@carmanconsulting.com> wrote:
>>>>>>>> If you change the group id, it's probably best to go ahead
and
> change
>>>>>>>> the package names also, in case two versions show up on the
same
>>>>>>>> classpath. Maven won't know that org.apache.commons:common-pool
is
>>>>>>>> the same as commons-pool:commons-pool, so it would potentially
put
>>>>>>>> both on the classpath. I believe there are also binary compatibility
>>>>>>>> issues (hence the 2.0), so changing that would mean we'd
want to
>>>>>>>> change it also.
>>>>>>>>
>>>>>>>> On Fri, Oct 15, 2010 at 2:34 PM, Phil Steitz<phil.steitz@gmail.com>
>>> wrote:
>>>>>>>>> +1 for 2.0. We should also talk about the ugliness that
we should
>>> probably also do for 2.0: o.a.c.pool2 or somesuch.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Oct 15, 2010, at 12:20 PM, Simone Tripodi<
>>> simone.tripodi@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all mates,
>>>>>>>>>> is this the right time to move the pool grouId to
>>> org.apache.commons?
>>>>>>>>>> Many thanks in advance,
>>>>>>>>>> Simo
>>>>>>>>>>
>>>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>>>> http://www.99soft.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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dennis Lundberg
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Dennis Lundberg
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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