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?
On Oct 16, 2010 10:21 AM, "Phil Steitz" <phil.ste...@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"<denn...@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<denn...@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
>>>>>> <ja...@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.ste...@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.trip...@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-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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dennis Lundberg
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
