commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] time to move groupId?
Date Sun, 17 Oct 2010 01:11:47 GMT
On 10/16/10 3:57 PM, Gary Gregory wrote:
> On Oct 16, 2010, at 10:21, "Phil Steitz"<>  wrote:
>> On 10/16/10 12:52 PM, James Carman wrote:
>>> On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton
>>> <>   wrote:
>>>> Consistency is good, but deciding something based purely on
>>>> *consistency* rather than the merits of the situation is mindless.
>>> Trying to keep things consistent is being mindful of the user's needs.
>>>   The consistency is part of the situation.  When you go to pool
>>> version 3, you'll have:
>>> 1.x - commons-pool:common-pool with package org.apache.commons.pool
>>> 2.x - org.apache.commons:commons-pool with package org.apache.commons.pool2
>>> 3.x - org.apache.commons:commons-pool3 with package org.apache.commons-pool3
>>  From what Dennis says above, it is not obvious to me that the artifactId change
for v 3 will be necessary - i.e., just bumping the version number will allow multiples to
be on the classpath at the same time.  Can someone answer this question definitively?  If
it will be necessary to move to pool3 later, then I agree with James that we may as well do
it now.
>>> Makes lots of sense to the users.
>>> Again, it comes down to "you don't work on this project so stay out of
>>> its damn business" and "the release manager is doing the work so they
>>> can do whatever the hell they want."  So, why don't we just do what
>>> Incubator does and have a mini-PMC for each subproject since you don't
>>> want other members of the Commons PMC butting their noses into a
>>> project they don't actively participate in?
>> I don't think that is what Niall meant and its certainly not how I see things.  A
great strength of our community is that we *welcome* input for one another as we make decisions
at the component level. We all benefit from that. The tricky bit is to agree on what we standardize
across components.  We have a long tradition of letting component communities and those who
step up to RM releases make a lot of decisions independently.  That does not mean that we
shouldn't listen to feedback from the community or provide it when we have something to say.
 Nor does it mean that we are not *all* responsible for *all* of our components.  Sometimes
we disagree and sometimes it takes a while to get to consensus, but IMO we are *much* better
off managing Commons as one community
> Yes! To me that's what the commons umbrella should provide.
> Let's reuse the lang3 experience for pool2. And move on IMO.


Sorry I did not understand what was going on at first. I am +1 for 
doing all three changes:

commons-pool -> org.apache.commons
commons-pool -> commons-pool2
org.apache.commons.pool -> org.apache.commons.pool2


>>> At this point, I really don't care what you guys do.  In the grand
>>> scheme of things, it has absolutely zero impact on me what you do with
>>> this code.  I'm tired of arguing about this stuff all the time.
>> I am sorry you feel like that atm.
>> Phil
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message