commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: Core architecture
Date Mon, 24 Jun 2002 00:21:23 GMT
All, thanks for bearing with me on this. I hope I can clarify my views:

Over the past few days I have become concerned that if I said nothing, then
Lang, Util, IO, Net, Reflect, Patterns, Thread, Resource, System... (all
these have been talked about)  would all be promoted to commons proper at
some point. This concerned me because:
- they would be promoted unchanged, because by the time they came to be
promoted, other projects would be using them, thus change (eg.to another
package name/component) would be considered unacceptable.
- each promoted component would be very small, perhaps with no more than 5
classes in them.
- the wrong mindset will have applied during the development of the
components in the sandbox. This is the most important one:

From: "Ola Berg" <ola.berg@arkitema.se>
> It is about (including but not limited to) taking the role of watching
that process, spot mechanisms that are used elsewhere too, propose common
interfaces in order to enhance interoperability, propose changes in other\'s
code, create the glue needed etc. Two questions that I hope says it all:
What if Comparable hadn\'t been? Or what if java.io.File had used a
Predicate instead of a FileFilter?

I think Ola is putting the point well here. FileFilter *is* a special case
of a Predicate. But because java.util doesn't contain such an interface
everyone writes their own version. The same applies to Transform. The same
applies to Factory. etc.  ie. in these cases, I don't think that the debate
would have arisen if the JDK was complete. But because they're not in the
JDK, we must provide them. And we must ensure that all projects use them (or
have a real debate about why not to use them)

This is why I fear the separate projects development methodology. It
encourages each separate project to develop parallel solutions to certain
concepts. By having separate solutions it becomes much harder (impossible)
for common tools to be developed on top of the interfaces. Such as GUI or
XML based tools to configure the Factories or Pools or Filters (predicates)
in a system in a common way.

From: "Steven Caswell" <steven@caswell.name>
> 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 o.a.c.io 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.

This is another well made point. The argument is that if someone came along
and said - I want to add a class to IO, but it depends on System, so you're
now going to have to make IO depend on System just for one extra little bit
on functionaity. Basically, adding a dependency to one of the current low
level projects appears to be something likely to be resisted, because each
component thinks of itself alone

From: Craig
* 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.

Unfortunately these classes all don't hang together and all do. They are the
stuff everyone has in their toolbox (a filter, a string helper, a clone by
serialization, a factory).

* 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.

The core code, almost by definition, doesn't have internals. Core classes
are typically a class named XxxUtils plus the interface (if its not in the
JDK).

* 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.

This is the biggest concern. But I disagree with the premise that smaller
projects helps. Because if the small project you're trying to release
depends on another of the low level small projects, which in turn depends on
two others, before you know it you've got to release schedule that is far
more complex.

I'll define the practicalities in another thread. Consider this the 'why'
thread!

Stephen



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


Mime
View raw message