commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [core] Scope, you choose!
Date Fri, 06 Dec 2002 18:05:53 GMT
My mail was meant to emphasise the different ideas/companents/packages that have been mentioned
over time. In particular they are the ones that are about assisting development with the 'core'
of the JDK.

I would suggest that if we follow the charter, and all of its theoretically marvellous principles,
then we end up with lots and lots of small jars.

I further suggest that this leads to either
a) duplicated code because components don't want to depend on other components for very small
amounts of code
b) a complex web of dependencies, maybe even circular ones

There is no simple solution here. I'm trying to point out that each solution has downsides,
and to provoke some debate.

My position? I agree that the charter's principles sound great and make perfect sense in theory.
However, I have grave doubts about them working in practice.

eg. if we create a [reflect], and that depends on [lang], then is [beanutils] prepared to
add two other jars as dependencies, or will [beanutils] (as I suspect) keep their own independent
copy of the code. 


>  from:    Rodney Waldhoff <>
>  date:    Fri, 06 Dec 2002 17:42:07
>  to:
>  subject: Re: [core] Scope, you choose!
> 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
> be.
> 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
> proposal.
> 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: <>

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

View raw message