commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [POOL2][PROPOSAL] releasing commons-pool2-2.0-beta1
Date Thu, 05 May 2011 17:27:38 GMT
On 05/05/2011 18:21, Phil Steitz wrote:
> On 5/5/11 9:42 AM, Mark Thomas wrote:
>> On 05/05/2011 17:33, Phil Steitz wrote:
>>> On 5/5/11 9:20 AM, Gary Gregory wrote:
>>>> I would like to propose an aggressive release schedule:
>>>> - Push 2.0 out as a generified version of 1.5 ASAP and add/remove/fiddle
>>>> nothing else. "Just give me the generics P L E A S E!" :) Change deprecated
>>>> documentation from "Will be removed in 2.0" to "Will be removed in 3.0".
>>> Why such a rush to just get generics?  Honestly, this makes no sense
>>> to me.  If you really want a type-safe pool, it is easy enough to
>>> wrap the methods that borrow and return objects.  If we make this
>>> decision, we are effectively deciding that the current pool API is
>>> going to be *the* API for several years to come.  We may also be
>>> painting ourselves into a performance corner supporting all of the
>>> features in the current API.  We won't know that until we really get
>>> the DBCP integration and performance testing done.
>> +1. The good news is that I now have some time to work on this.
> Great!
>> The first task will be updating dbcp/trunk to build against pool/trunk.
> +1 - but lets try to minimize the changes for now to those necessary
> to get the build to work (i.e., hold off on internally
> "genericising" DBCP).  This will make it easier to port bug fixes.

OK. I've already added the @Override markers but that shouldn't cause
too much pain. I'll hold off the generics changes for now and focus on
pool2 performance.

>> I suspect we are going to need at least a snapshot build of pool/trunk
>> to keep the Maven deps happy.
> I wonder if it would be just as easy to just move to using Ant for
> this phase of dbcp development and either build a pool jar or just
> pull in the required pool sources?  I would personally be fine with
> that approach.

My own plan (which is working already) is have the Tomcat DBCP/jdbc-pool
performance tests as one Eclipse project which in turn depends on an
Eclipse project for dbcp2 which in turn depends on an Eclipse project
for pool2. I don't actually care right now that both the Ant and Maven
builds for DBCP are broken. Others (and the CI systems) might ;)

One option (that might also work for Gary) is to start producing
snapshot builds of pool2.


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

View raw message