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 - practicalities
Date Mon, 24 Jun 2002 00:54:02 GMT
From: "Stephen Colebourne" <scolebourne@btopenworld.com>

Whats in - simple standalone pieces of functionality
  - too small to be alone
  - so essential that everyone should be considering them
  - typically one interface and an associated XxxUtils class, or just the
XxxUtils class if its a JDK class
Whats out - large pieces of functionality
  - where enough classes exist to stand alone
  - where not every project will necessarily use them

Now this gives plenty of scope for argument! So...

Whats in - (not specifying exact package names)
Lang - Objects, Strings, Numbers, ...
Lang - Serialization
Lang - Exceptions
Util - BitField
Util - Comparators
IO - All
Collections - Predicate, Transform, Closure, Comparators
BeanUtils - MethodUtils
Reflect - other low level reflection code, eg. ConstructorUtils
BeanUtils - Convertor (but reworked considerably)
Patterns - No code yet available
System - No code yet available
Pooling? - No code yet available - may deserve to be alone

Whats out
Net (big enough alone, not essential)
Thread (big enough alone - potential to grow, not essential)
BeanUtils (handling of beans, established, big enough alone, alternatives
available)
Collections (the collections, big enough alone, people can get by with java
collections)
DBCP, Betwixt, JXPath, Digester, ... (big enough alone, serve more
specialised needs)


This is about project management as much as about writing code. For example
Pooling and System have been suggested, yet there is no code. Thus...

we need a sandbox  ;-))

Sounds daft?? Not really. There's nothing really wrong with the sandbox
concept of lots of small projects doing investigatory work. (do what you
like, change the API, mess it around day to day). Thus System, Patterns and
Pool should become sandbox components.

However, there needs to be a gathering stage where those parts which look
good, are separated from those parts which still need work. And this needs
to occur *before* the component becomes well used. Definitely *not* at the
last minute before release.

Thus my concept of Core is as a gatherer project management mechanism. An
extra stage between true sandbox  and the released code in commons proper.
Once release 1.0 of core occurs, the rule is that new classes are added to
the sandbox first, rather than just seeing core expand with every new idea.

Stephen
(Its 02:00 now so I hope that all that makes sense ;-)



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