commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Commons architecture
Date Sun, 23 Jun 2002 22:18:46 GMT

On Sun, 23 Jun 2002, Steven Caswell wrote:

> Date: Sun, 23 Jun 2002 16:55:22 -0400
> From: Steven Caswell <>
> Reply-To: Jakarta Commons Developers List <>,
> To: 'Jakarta Commons Developers List' <>,
>      'Ola Berg' <>
> Subject: RE: Commons architecture
> I'd like to weigh in as a very interested lurker. I've got bits and
> pieces of things laying around from various places, many of which came
> from different corners of jakarta that I've taken out and abstracted (or
> thought about if I'd had somewhere to put them). The main reason I
> haven't tried to submit these back is that there has not been a good
> place to put them.
> IMO one important consideration is that some of the core classes will
> likely depend classes in other core packages. For example, I've found
> some good io stuff in Ant that I'd like to pull into that will
> probably depend on at least one other class in another area of the core
> (o.a.c.system maybe). I'm guessing that this will be easier to do if
> there is one subproject as Ola suggests.

Taken to an extreme, this approach would lead to a single
org.apache.commons.kitchensink package :-).

To me, the best dividing lines between subpackages in commons are based on
the following concepts:

* Coherence -- All of the classes in a particular package should
  "obviously" belong together.  Either they need each other, or they
  illustrate different ways to implement the same abstractions,
  or they probably shouldn't be together.

* Shallow Interdependencies -- It's fine for Commons projects to depend
  on each other, as long as they do so at the "edges" of the public
  API of the other packages.  For example, packages dependent on
  commons-logging are encouraged to use LogFactory and Log (and even
  create your own implementations if desired), but deep linking into
  the internals is a sign that maybe your classes should really be in
  the other package instead of separate.

* Releasability -- The larger a commons package gets, the slower its
  release cycle must be, due to the added testing and the need to get
  all of the classes to a roughly equivalent quality level (and then
  hold) for long enough to get the release out.  Smaller, more narrowly
  focused class libraries are easier to release separately.

All of the commons projects that I've been involved with as a developer
(primarily beanutils, digester, logging, modeler) are relatively small and
narrowly focused -- 1-5 key classes (with supporting machinery as needed.
There are cross-package dependencies, but only on public APIs that have
stayed quite stable.

Collections, although quite coherent, is getting so large that I can't
always assume a new collection class that I might want to contribute to it
will become part of a released version of collections (so I can publish a
dependency on a particular version x.y) in a timely manner; making it more
likely that I'd just stick it in the "util" subpackage of my own package

At the same time, refactoring is a fact of life.  For example, I'm fine
with extracting the introspection/reflection stuff out of BeanUtils into
either one or two finely grained other packages (there is probably enough
mutual interdependence to be worth combining), and making the existing
MethodUtils class et. al. a backwards compatibility wrapper.  I'd even
help out in such an effort.

I'm not very keen, however, on making my package dependent on some
gigantic wad-o-classes that might have a real release every couple of
years.  Totally independent of technical quality (assumed to be the same
in either case), I simply need the flexibility to get faster turnaround on
new features added to the packages I establish dependencies on -- and
that's more practical with lots of small packages than fewer large ones.

> Steven Caswell
> a.k.a Mungo Knotwise of Michel Delving
> "One ring to rule them all, one ring to find them..."

Craig McClanahan

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

View raw message