On 26.07.2013 00:34, Mark Thomas wrote: > On 21/07/2013 09:10, Mark Thomas wrote: >> On 20/07/2013 17:42, Konstantin Kolinko wrote: >>> 2013/7/18 Mark Thomas <ma...@apache.org>: > > <snip/> > >>>> Any objections to starting the 8.0.0 release process? >>> >>> What do we do with DBCP? >>> >>> a) There will be a new release in Apache Commons >> >> That requires a pool 2.0 release and then a dbcp 2.0 release. >> >>> b) Require "patch" tool as prerequisite >>> (It needs to be explicitly installed and configured on Windows) >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=54522 >>> >>> c) Make DBCP optional, e.g. introduce "skip.dbcp" property like >>> existing "skip.installer" one. >>> >>> d) Drop DBCP pool >>> >>> I am currently using a variant of "c)" by setting "no.build.dbcp=true" >>> (thus fooling an up-to-date check), but an explicit and documented >>> property would be better. >> >> e) ship a dbcp version built from svn rather than a release. >> >> >> My own preferences (in order) are: >> >> a, e, b, c, d >> >> I'll see what I can do to towards a. > > There is quite a bit of work for DBCP2 as a lot of things have been put > off got a while (I fixed a 9 year old enhancement request earlier this > week) as they require API changes. > > I've been thinking about this a little more and I think there is another > option that works better for Tomcat 8. > > svn copy and package rename DBCP2 and POOL2 to org.apache.tomcat in the > same way we have handled Commons BCEL, Codec and FileUpload > Pros: > - can make early versions of DBCP2 available for testing with Tomcat 8 > - simpler build process > - easier to make source changes (we are going to have to make changes > because DBCP adds Commons-Logging) > - can switch to tracking released revision numbers at any point (once > there is a release to track) > - option to remove code we don't use > > Cons: > - more work to keep in sync than just changing a version number in a > property file > - requires effort to set up > > My outline plan is to do this early to middle of next week with a 8.0.x > release (8.0.0-RC1 to be consistent with how we did 7.0.x) towards the > end of the week. > > Thoughts?
That would be especially good if DBCP2 could hold back their release until our fork has stabilized and synced back so that the DBCP2 releases can from then on be used as the master for our copy. Otherwise we would have to live for a long time with a diverging fork, because DBCP2 might have already frozen their API due to the first release. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
