[all commons] Proposal: CommonsCommons package

[Ola Berg <ol...@arkitema.se>]

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

--------------------
ola.berg@arkitema.se
0733 - 99 99 17

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [all commons] Proposal: CommonsCommons package

[Stephen Colebourne <sc...@btopenworld.com>]

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" <ol...@arkitema.se>
> 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
>
> --------------------
> ola.berg@arkitema.se
> 0733 - 99 99 17
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [all commons] Proposal: CommonsCommons package

["Michael A. Smith" <ma...@apache.org>]

I've actually been thinking about this for a while.  The transform stuff
and predicate stuff that is in the collections project doesn't
necessarily need to be "restricted" to collections.  That is, they
probably should exist outside of collections and have collections depend
on them.

However, I don't like the idea of a commons commons.  I dislike it for 
the same reasons why this forum rejected the idea of a commons "util" 
component.  

Instead, it would probably be appropriate to move these into other 
commons projects.  For example, "lang" or "codec" (for transforms).

regards,
michael


On Sat, 15 Jun 2002, Ola Berg wrote:
> 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
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>