commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] What's needed for a release
Date Thu, 17 Nov 2005 22:12:27 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message