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 [logging] distribution and packaging [WAS Re: [logging] What's needed for a release]
Date Sun, 13 Nov 2005 21:09:09 GMT
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>

> > > 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. 
> 
> IMHO the real decisions needed are:
> 
> 1 our jar distribution strategy (in particular, whether we ship the
> optional jar or not)
> 
> 2 how we give downstream packagers and users a fair view of the actual
> JCL dependencies
> 
> i'll move these two important and related issues to a separate thread.

and here it is :)

i've had a chance to reflect on this in the months since it was last
discussed. for end users, i'm now inclined to agree that we need to keep
the number of jars short. this should make it easier to explain to users
how they can troubleshoot common problems. i think that the
demonstration code is a good starting point for a troubleshooting guide
similar in tone to the tech guide.

i would like to offer the content in the optional jar but there are
other ways this might be done. for example, we might offer a separate
commons logging extras distribution. 

some of my concerns about end users understanding the dependencies can
probably be addressed through documentation. i've added comments to the
maven dependency document and we could add a table explaining the
dependencies to the JCL home page. 

what's really needed by downstream packagers is to be able to know the
actual minimal core dependencies for a functional JCL. perhaps we could
address this by documentation and changes to the build script.

opinions welcomed :)

- 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