Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of
 robertburrelldonkin@blueyonder.co.uk designates 195.188.213.7 as permitted
 sender)
Subject: Re: [logging] make dependency on servlet api optional
From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <1120348264.3926.19.camel@localhost.localdomain>
References: <NBBBJGEAGJAKLIDBKJOPEEDCCBAC.noel@devtech.com>
	 <1120101043.3783.38.camel@localhost.localdomain>
	 <42C6EB22.5080207@yahoo.de>
	 <1120348264.3926.19.camel@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-1
Date: Tue, 05 Jul 2005 23:47:49 +0100
Message-Id: <1120603669.5044.23.camel@knossos.elmet>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Sun, 2005-07-03 at 11:51 +1200, Simon Kitching wrote:=20
> On Sat, 2005-07-02 at 21:29 +0200, J.Pietschmann wrote:
> > Simon Kitching wrote:
> > > This is only a *compile-time* dependency.
> > >=20
> > > Currently there is a single utility class provided in the standard
> > > logging jar which can be used to avoid memory leaks when using
> > > commons-logging in servlet containers.
> > >=20
> > > The presence of the class doesn't do any harm when used in
> > > non-servlet-containers; commons-logging will run fine and the class i=
s
> > > simply not used.
> >=20
> > There's a recurring problem: projects developing into kitchen-sinks
>=20
> I don't believe this is the issue here. Commons-logging has a very
> definite focus so arbitrary feature growth is not really a danger.
>
> The memory-leak-in-servlet-engine issue is a common problem and does
> need to be addressed one way or another. Taking a wild guess, I would
> think that perhaps 50% of all uses of commons-logging is in a J2EE or
> servlet container, so including this code in core seems reasonable to
> me.

that depends on whether the concept of core comes from a dependency
perspective or a usage perspective. there are advantages in structuring
builds so that dependencies can be managed most effectively and then
distributing a combined headlining jar containing the most popular
classes.=20

> > I had to build Apache software from source multiple times for debugging
> > purposes, and I don't like to track down all of the obscure compile
> > time dependencies. Nor do I like to wait half an hour until all
> > dependencies have been fetched from ibiblio or whatever.
>=20
> Tracking down obscure compile time dependencies is not an issue; they
> are all right there on ibiblio. And we can provide an Ant task to
> download them.
>=20
> I guess for people on dial-up connections the download time could be a
> nuisance.

in my time, i've also spent too long tracking down obscure references
when wanting to build a project just to hack a simple fix. (if you want
real pain, then i'd suggest setting up a full gump run on a local
machine.)

but i agree with simon that maven now solves this problem very well.
(indeed IIRC, this issue was one of those that maven was created to
address.)=20
=20
> > I'd prefer a more modular approach:
> > - Split the project (preferred, but not all that easy)
> > - Provide several build targets according to dependencies
> > - Compile "optional" (non-core, or less likely to be missed) components
> >   or features only if libraries they depend on are in the classpath.
> >   Issue a warning otherwise: "Component/Feature FooBar not compiled
> >   because FooLib not found..."
>=20
> This is pretty much what commons-logging currently does. So obviously
> people share your view.

there are several reasons why experience has taught that this approach
often proves the best (i'll give some reasons for this statement at the
bottom rather than break up the flow now). however, the modularity in
the current build isn't as clearly reflected in the project structure as
it might be. it might be worth considering a move to a structure better
reflecting this (which may be J=F6rg's suggestion).

i'm not really sure that the layout adopted works very well (a separate
optional directory) and now we use subversion, it's cheap to reform the
layout. (i do want to move the demonstration out sometime soon BTW.)  =20

> However it complicates things:
> * build.xml harder to read and maintain. For example, if building
>   various parts is optional, then all the related unit tests also
>   need to be made optional, and run only when the corresponding
>   parts are present.

true

it's easier to go for an explicit module structure rather than use build
tricks

> * we need more documentation, and more complex instructions for users.

true

however, i'm now of the opinion that JCL requires lots more
documentation than it has. IMHO optional jar's are much easier to
explain than classloading.

> It has to be remembered that commons-logging is generally something that
> people don't deliberately use; it's a dependency that is dragged along
> with some other lib that they are really interested in. So people don't
> have much interest in reading docs or configuring it correctly.
> Commons-logging really needs to work out-of-the-box as much as possible.

+1 (but we all know how difficult that make it for us :)

> And already people moan about having to include commons-logging.jar when
> using commons libs like digester or configuration. Providing them with
> complex documentation indicating under what circumstances they need to
> include additional jars won't make commons-logging more popular.

+1

this can be addressed by looking at the jars we distribution. what works
well with a modular approach is to separate the builds but distribute a
fat jar (containing everything) as the standard (named) jar.

adopting this policy would lead to a distributing something like:

commons-logging.jar (containing everything) =20

commons-logging-core.jar (containing everything but optional)
commons-logging-optional.jar (optional stuff including deprecated)
commons-logging-api.jar=20
...=20

> > Take a look at the FOP build file to see the third approach in action.
>=20
> Yes, but FOP is quite a different beast from logging. People explicitly
> download and use FOP, while people usually get commons-logging as an
> accidental side-effect of some other lib.

AIUI FOP is also used quite extensively as a library so it has some
similarities as well as differences.=20

> And commons-logging is only half-a-dozen classes while FOP is -- just a
> little bit larger!

that's certainly true!


monolithic builds sooner or later run into difficulties with
dependencies. these difficulties come in different forms.=20

there is the issue of dependency proliferation. the fight against
dependency proliferation means that good code that is only useful in a
limited number of use cases is not accepted whereas the ill effects of
drifting towards kitchen sink dependency are well known. monolithic
builds have to err on the side of caution.=20

sooner or later, it is necessary to cope with dependencies which break
backwards compatibility. monolithic builds are usually force to adopt a
single choice of dependency. this causes major pain to downstream users
by forcing a particular choice of library versions upon. it is often
possible to structure modular builds so that different versions of the
same library can be supported.

JCL is used by a huge number of downstream users. a failure in the JCL
gump build (a good metric) causes a gump storm containing hundreds of
consequent failures. gump is an example of a dependency management tool.
maven is another. the number of dependencies required to build a basic,
functional JCL is small (though larger than it should be). if the basic
build compiles more than is strictly needed by dependent, then this
causes problems for dependency management tools. in this end, this may
also prove a source of difficulties since JCL may end up depending
(indirectly) upon itself.

these forces often result in monolithic builds tending towards modular
ones.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org