On Tue, 2005-11-15 at 07:47 +1300, Simon Kitching wrote: > On Sat, 2005-11-12 at 13:00 +0000, robert burrell donkin wrote: > > On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote: > > > On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote: > > > > On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote: > > > > > > > > <snip> > > > > > > > > > > Can a new release of CL rule out all the classloading problems > > > > > > people had before? > > > > > > > > > > > > > > > What's currently in SVN head will probably fix 90% of the problems, > > > > > and > > > > > is about 99% backwards compatible. I would love to see it released, so > > > > > that the debate could then move on to a "JCL 2.0" which I think is > > > > > quite > > > > > likely to take the alternative approach described above. Oh for a few > > > > > more hours in the day! > > > > > > > > what work's required for a release (above the actual code cutting)? > > > > > > * Remove the ServletCleanupContextListener (this might not be exactly > > > the right class name). It's obviously too controversial. Maybe the code > > > could be put in the documentation somewhere, or on the wiki. > > > > i'm +1 for the class to be distributed. my main concern was about the > > best way to do this sympathetically. > > Well, I'm not too worried about simply removing the servlet class from > the distribution for now. It's only one class, and not very long, so > having it in the documentation rather than the actual distribution is ok > I think. > > I would much rather have a release out with this class in the docs than > spend a lot of time considering generic mechanisms for handling complex > dependencies. Let's just remove the class for now and debate dependency > management issues for this sort of issue in the next release cycle...
i wasn't thinking of anything particularly complex. i've been thinking and my concerns could be addressed by some documentation and a new build target (for a minimal build from source). any objections to this plan? we need to decide about the future of the optional jar. i think i've come around to the think that users are going to be confused enough just with the jars that are needed to support various classloader combinations. i'd like to keep the code but the current location isn't all that good. i have a few more ideas (if i ever find the time) for useful (but not core) functionality. so, one possibility would be to push for a separate JCL extras/ JCL utilities component. another would be to off-shore the codebase. opinions, please :) this doesn't need to be decided right now: the directory can be parked somewhere convenient in subversion. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
