commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject Re: [core] Scope, you choose!
Date Fri, 06 Dec 2002 17:42:07 GMT
I disagree with a number of things here:

1. The definition of "core commons components", or for that matter, the
very notion of a "core" set of commons components defined by anything
except for the dependency graph.  The collection of components I would
consider core are different from yours, and I suspect they are both
different from what some third party might consider to be core.  (Indeed
your "core" set includes components that only exist in the sandbox, so we
don't yet even have formal consensus that they should exist in
jakarta-commons.)  The concept of defining a core set of components is
flawed IMO, nor do I see what the benefit of such a categorization would

2. The expression "Here are the tasks currently/planned for".  Planned by
whom?  I don't recall any sort of roadmap being proposed for this, nor any
vote.  This is really your proposal (perhaps agreed to by some others) of
what should happen, yes?

3. You write:

> Why are Functors in [lang] ?

> Because they are not specifically related/restricted to collections.
> Because other projects, eg. [io], [clazz] want to use them and don't
> want to depend on [collections].

but your answer only explains "why aren't Functors in [collections]?".

similarly, you write:

> Why is Reflection in [lang] ?

> Because its not specifically tied to beans. Because other projects, eg.
> [clazz] want to use reflection and don't want to depend on [beanutils]

but your answer only explains "why isn't Reflection in [beanutils]?".

4. You write:

> Where would you draw the scope lines? Do we just follow history? Or try
> to improve?

I think that the approach taken here is working backwards.  The right
approach (IMO) and the approach endorsed by the commons charter is to
articulate a component's scope and then propose it, not to partition the
universe of functionality into existing (sometimes sandboxed) components.
We shouldn't be "draw[ing] scope lines", we should be defining cohesive
components.  If some components have overlapping scope, that's OK
(formally).  If we want to refactor the scope of one or more components to
reduce this overlap, I think that's generally a Good Thing, but at minimum
that represents a product change (and hence requires a formal consensus
vote), and should IMO be handled in largely the same way as any component

5. You write:

> It all comes down to how big or small you want your jar files.  And
> whether [beanutils] and [collections] are prepared to add [lang] (or
> _any_ other > jar) as a dependency.

It doesn't come down to that at all.  JAR file size is independent of
component partitioning. It comes down to:

a) Are these classes likely to be used together (i.e., if I use one will I
use the other)?

b) Are these classes likely to be changed together (i.e., if I change one,
will I change the other)?

If the answer to both questions is "no", then it is unlikely that the two
classes belong in the same commons component.  Note that this is what we
really mean when we say <component x> "doesn't want to depend on"
<component y>--we're saying that <component y> isn't a cohesive
component--I want some if its functionality but not all of it.

- Rod

> Stephen

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

View raw message