On 22/03/2011 18:4, Gary Gregory wrote: > On Tue, Mar 22, 2011 at 2:20 PM, Mark Thomas <[email protected]> wrote: > >> What do folks think to the following: >> - move pool trunk to a POOL_FUTURE branch >> - restore pool trunk to a copy of the POOL_1_X branch >> - rename pool package to o.a.c.pool2 >> (in reality this would probably be a merge from POOL_FUTURE) > > Why not just use pool2 trunk then? I guess you'll have to try and see.
I started that a few hours ago and my initial impression is that there would be a lot of work to get dbcp2 working with pool2. It just feels like much too big a leap. I'm much happier with small incremental changes. >> - rename dbcp packages to o.a.c.dbcp2 >> - get pool2 and dbcp2 working together >> - get Tomcat trunk working with dbcp2 >> - go through the POOL_FUTURE changes one at a time: >> - merging it into pool2 trunk >> - updating dbcp2 trunk if necessary >> - testing updated dbcp2 with Tomcat >> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that >> can't easily be fixed skip that change and leave it in POOL_FUTURE > > I'd hate to see all of the pool2 work tossed aside but I do like the > evolutionary approach of getting pool2, dbcp2 and Tomcat changing in > lockstep, one commit at a time. Right it sounds like you are saying that > pool2 is different enough from pool1 to be a big pain for dbcp2 and Tomcat. Yes, right now moving to pool2 is a huge obstacle. The intention of my proposal was to provide a way of keeping most of the POOL_FUTURE changes whilst allowing incremental changes in dbcp2. svn merge should mean minimal additional work to merge back POOL_FUTURE changes to pool2 trunk. With luck, we should be able to skip over any problematic POOL_FUTURE changes and discuss those in more detail before deciding what to do. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
