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 practicality. Stephen From: "Ola Berg" <[EMAIL PROTECTED]> > 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 > > -------------------- > [EMAIL PROTECTED] > 0733 - 99 99 17 > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
