commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add collecting of statistics to pool implementations)
Date Fri, 26 Apr 2002 18:54:06 GMT
From: "otisg" <>

> If Excalibur, which is a part of Avalon, is a set of micro components,
> why nor merge them with Commons? From another email I see that a group
> of people (Avalon) already tried doing that a while ago, but failed, so
> Commons was created.
> I don't want to start a long discussion, I'm just wondering what's the
> reason that hasn't or can't be done, or to put it more positively, how
> we can get that done.

I have tried myself to make projects cooperate on Jakarta, and there are
cases in which one part simply refuses to do it.

This is the reason why there are duplicate projects, and why projects keep
making subprojects that have less an less to do with the original project.

It seems to me, and to many outside viewers, that there is a sort of anarchy
in the way subprojects are created, making code duplication a reality.

There is not a unified vision, if not the Apache license and the "server"

I can live with this, and I see that it can bring good things. If projects
compete, they can benefit from each other, since the source is there to see
and the license permits it.

The downside is how we are seen from the outside...


IMHO Jakarta should favor the use of common interfaces.

Interfaces can become standards, and this is how Apache can create
"de-facto" APIs.

This way projects can give the user functionality without locking him into
their API for common functionality.

What about *Commons-API*?

Nicola Ken Barozzi         
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message