commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [all commons] Proposal: CommonsCommons package
Date Sat, 15 Jun 2002 20:30:07 GMT
I know what you mean, but I'm not sure that commoncommons is the answer.
IMHO, code in the commons falls into three categories -
- Widely used, and often as a group (BeanUtils, Betwixt, Collections,
Digester, Logging)
- Individual stable, less interrelationships (CLI, Cactus, DBCP, HTTP
Client, ...(other commons))
- Developmental code (Sandbox)
I know I might be a little controversial to separate out those 5, but they
do often seem to be used as a group. (And this also affects the people
working on them.) Something to tie the three groups together could be
useful, but it could also be troublesome.

Predicate, Transformer, Closure, and Factory _could_ all be separated from
collections. But they are not big enough to exist on their own. (Plus moving
gives backward compatability issues). Even adding some extra interfaces
doesn't really make the case. You suggest Named (or Nameable ;-) although
I'm not sure what advantage/use it gives. Earlier today in a betwixt
discussion I suggested Identifiable.

Transformations is a particularly complex case. There is collections'
Transform, beanUtils' ConvertUtils, Betwixt and Digester in their entirity,
and the new Morphos in the sandbox.

One possible solution is to resurect the lang sandbox package which seems to
be asleep and add these things to it. Then say everything depends on lang.
The real trouble is deciding what is truly absolutely unquestionably common
however. If you've seen a logging flame war, you'll know that the more
common it is, the higher the tendency for problems.

My view: there is merit in this proposal., but I have some doubts about the


From: "Ola Berg" <>
> Having looked at the code of almost all commons components, I see that
there is a need for a base package that solves many generic problems, that
today is solved differently within the packages.
> Candidates for such a package includes:
> Transformations - generic transformations (including type conversions and
the special and often used conversion: creating Objects from Strings, which
is tightly linked to a common factory platform wich is needed both in pool
and in configuration which is needed in...)
> Predicate - Very useful.
> Also a number of common interfaces that guarantees that the class follows
a certain pattern, like Named = all classes that has a String name property
etc, which enhances reuse between the packages.
> This could also be a good spot for 1) an architectural birds view on the
packages, and 2) potential migration to a merge effort so that each commons
component could drop their special implementation of a feature as soon as
the same feature in commonscommons feels OK.
> I bet there are some design descisions that would have been better today
than when it started (\"Oh, why didn\'t we let X inherit Y from the
beginning?\"). commonscommons (no I don\'t propose that name) could be the
place for such \"second\" tries.
> /O
> --------------------
> 0733 - 99 99 17
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message