commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Date Fri, 26 Apr 2002 15:52:19 GMT
Henri Yandell wrote:

<snip/>

> If Avalon is a macro view made up of micro components, and Commons is
> micro components, when will we hit a stage where we have a redundant
> micro-components project, and how should this be dealt with?

Avalon started as a collection of lessons learned from the Apache JServ
project.  It was built to abstract out the common patterns that were in
that project and could be applied to other projects.

A couple of other projects were started to test the theories: Apache
JAMES and Cocoon.  Both of those projects have contributed information
back to Avalon that has helped it be better.

As always happens with frameworks (Turbine included) is that it grew
in scope, and the needs it was satisfying.  It was no longer a list of
patterns and best practices, but a collection of useful code that could
be used in a number of different packages.

So now Avalon has the framework (aka Framework), micro components (aka
Excalibur), a logger (aka LogKit), macro components (aka Cornerstone),
and a microkernel based server (aka Phoenix).

The most clash that occurs with Commons occurs in the Excalibur package.
I don't recall the whole inception of Commons very well, but I
believe we lobbied unsuccessfully to merge Excalibur and commons before
commons was created.  Again I could be wrong on that point.  There are
cultural differences between the two communities for sure.  That is
one reason for some of the duplication.  Another reason is the fact that
the Avalon site is not yet set up to plainly declare what we have,
something that commons is a little better about.

We are working on these issues so that it is easier to find out what
exactly lives in Avalon and what is in Commons.  The user of the
software will be able to make an *informed* decision of which project
they want to use.

> 
> My definition of macro vs micro is probably best expressed as giving
> someone a lego kit in a box versus giving someone lots of lego bricks. In
> the former there is a defined way to build the system, though you can play
> with it. In the latter it's entirely up to you.

I think that is a good analogy.  Although you can still take legos from
different kits and come up with new creations. :)  I used to do that all
the time.  In some ways, I still do.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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