commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject [logging] dependencies [WAS Re: [logging] new release?]
Date Sun, 09 Oct 2005 09:38:25 GMT
On Fri, 2005-10-07 at 22:16 +1300, Simon Kitching wrote:
> Hi All,
> A week or so ago I was prompted by new activity on the logging topic to
> review what is currently sitting in SVN. I think it's actually quite
> good, and perhaps we could try to push for a release.
> The issues I'm aware of are:
> * Do we include the ServletContextListener stuff or not? And if we do,
>   do we put it in an "optional" jar or in the main jar?
>   Personally, I would like to include it, and put it in the main jar.
>   It does no harm being there, as no logging classes reference it. It
>   only gets used if someone explicitly references it from a web.xml
>   file. 
>   There have been objections about adding "dependencies", but JCL is
>   a project that already has heaps of compile-time dependencies that
>   aren't actually runtime dependencies, eg LogKit is a compile-time
>   dependency too, but isn't needed to run.

i think that there are a lot of different issues here which could do
with being untangled. i'll make a stab at outlined the different ones i
see (possibly with a few to documenting later). please feel free to kick
off discussion (i've refrained from presenting solutions) and add any
i've missed.

downstream maintainers
my major concern was about the impact of JCL dependencies on downstream
maintainers (rather than users). this include the gump infrastructure
and packagers such as debian. JCL is now a really basic component right
at the bottom of the java package tree. 

in the best case scenario, more dependencies mean that maintainers have
more work to do. in the worst case scenario, maintainers will be forced
to remove JCL and all packages that depend upon it from their
distribution. for example, debian will only ship java libraries that
will run on a free JVM. so, the impact of adding an innocuous dependency
may be that downstream maintainers are forced to remove scores or
hundreds or packages from their distributions.

perceived dependencies
a different concern is that users are given the wrong impression of the
libraries which are required to run JCL. this includes users who feel
they need to find and download sources for all dependencies and those
who need to distribution and run a minimal stripped down version. what
classes and dependencies are required is a FAQ. 

solution specific jars
we ship a number of jars to help users configure JCL effectively in
containers with complex classloaders. this will allow better
documentation to be created describing how to configure JCL effectively.

however, the complexity (and possible confusion) of shipping additional
optional jars is increased by the fact there are already multiple
versions of the core shipped.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message