Just for the record, might as well get this out now :-) I'm going to take a fairly STRONG position against fixing discovery in a 1.0.6 if that is the ONLY change going in. Why?
- The "fix" I envision will necessitate "backwards incompatible" behavior in a "standalone" commons-logging.jar file. This requires more than a point release. - commons-logging 2.0 should default to a simple discovery process very much in line with the UGLI discovery [typical J2SE configuration], and give up all attempts for managing complicated ClassLoader hierarchy problems. - commons-logging 2.0 should to defer to commons-discovery, if commons-discovery is available in an appropriate class-loader [and yes, this means "discovering" commons-discovery... headache time.. but we'll keep it simple anyway :-) right?]. - I want to "fix" the ClassLoader problems in commons-discovery. - Specifically, allow the commons-logging 2.0 + commons-discover X.Y to function well under J2EE and OSGI environs... or any other complicated ClassLoader environment. Now, all that aside, someone is going to argue that we should "go ahead" and fix the ClassLoader problems in 1.0.6. All well and good, but note that I want to *encourage* use of the new branch, and let the old branch rest piecefully [did I say die? I didn't say die... did I?]. If you want a "sophisticated" discovery mechanism in complicated ClassLoader environs, then defer to the new "pluggable" discovery mechanism and be ready to work in OSGI, J2EE, or whereever. If you don't need it, then what comes in commons-logging.jar will be sufficient for simple J2SE applications. <ras> ******************************************* Richard A. Sitze IBM WebSphere WebServices Development robert burrell donkin <[EMAIL PROTECTED]> wrote on 02/07/2005 04:16:42 PM: > back up and running now :) > > i propose to take a branch for the 1.0.5 release as soon as the > outstanding matters have been discussed. this will free up head for > possible work either towards a 1.0.6 (with improved discovery) or a > major revision. > > brian contributed the required documentation (many thanks) so all that i > have on my list now is to work out which bugs will be addressed for this > release. here's the analysed consensus from the wiki (thanks to dennis > for his review). please feel free to jump in and disagree if > appropriate. > > in the event of no complaints, i propose to update bugzilla and take the > 1.0.5 release branch some time after 2200GMT tomorrow (tuesday). anyone > with a problem with this plan should jump in now... > > - robert > > Open Bugs > --------- > > Bug 28291 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 > Classloader related, these issues will be addressed by later > releases > > Bug 30131 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30131 > This is related to httpclient example code but Dennis posted a > followup (with no response) and I've check the example code (which looks > ok to me). > > Bug 30268 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=30268 > Needs architectural changes > > Bug 30632 CLOSE http://issues.apache.org/bugzilla/show_bug.cgi?id=30632 > See 30131 > > Bug 32618 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 > The new proposal by IBM. > > Bug 32662 WONTFIX > http://issues.apache.org/bugzilla/show_bug.cgi?id=32662 > See > http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=110780577017737&w=2 > > Bug 32691 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=32691 > General heading of improvements to API. (Needs a champion.) > > Bug 33347 LATER http://issues.apache.org/bugzilla/show_bug.cgi?id=33347 > API improvements. (Needs a champion.) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
