avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Re: Breaking Excalibur into smaller swords (was Re: Synergies between Avalon and Commons projects ?)
Date Tue, 25 Dec 2001 16:24:04 GMT
Berin Loritsch wrote:
>
>> I do believe that people really want to reuse already coded and debugged
>> components.  It is when such components come with strings attached that the
>> hesitation begins.
>
> Understood, another issue comes when using code not developed with Inversion
> of Control in an environment  designed for Inversion of Control.  All the
> benefits of that design principal/pattern are lost.
>
> The only time you can mix the code is when the environments are sufficiently
> decoupled.
>
> Also, I would like to see some usage stats for Jakarta Commons.  Honestly,
> your argument is under the supposition that Commons is more popular or well
> known than Avalon.  Arguably, Avalon has had a little more press as we have
> been "advertising" releases to a number of different news portals.

Is that my argument?  If so, I don't recognize it.

This is only one data point, and anecdotal at that, but Axis has a small -
one class - command line utility package.  You suggested that Avalon
Excalibur be used instead.  The initial reaction was that that was
significantly overkill.  You succeeded by being able to demonstrate that
the component was, in fact, decoupled.

My argument is that small, decoupled components will see greater use than
large tightly coupled components.

Inside the avalon family of cvs trees there are such components.  However,
by virtue in their placement in an Avalon cvs tree, the perception is that
the emphasis is on the integration instead of the reuse potential.

> While this does seem like alot, there are also some other things we must
> consider.  First and foremost, we would no longer be in control of their
> development life.  Because some of these pieces (pooling, thread pooling,
> concurrent, and collections to name a few) are so critical to the way
> things work in Avalon, it is a scary thing to give up that control.

Get over it.  ;-)

One thing for sure, I can alert you - generally within 24 hours - after
such a change goes into development.  That should give you plenty of
opportunity to block incompatible changes from ever making it into a
release.

> 1) I personally don't have the energy/time to support yet another project,
>    but I can support these utilities where they are now.

Let me get this straight - if "x" is renamed to "y" you have time, but if
it is renamed to "z", you don't?  The argument seems specious to me.

There are several projects in Apache, like Ant and Cocoon, that would
clearly survive if the top leader or three were to all disappear.  There
are others, like Gump and parts of Avalon, that exist by the sole virtue of
a single person - or at most a small number of people's - dedication.

We need to continue to strive to find ways to convert projects of the
latter type into the former.

> 3) These utilities could possibly die in commons, where they would survive
>    in Avalon.

The reverse is also true.  Generally, the place where the code can gather
the largest community is the one with the best odds for success.

> 4) Commons could so tightly integrate the utilities that they no longer
>     able to be used without additional cruft we have no interest in.

That is essentially against the charter of Commons.  However, well within
the charter of Avalon, which is why I would suggest that a move to commons
might allay some people's fears and increase the size of the community.
But clearly this should only be contemplated for small, decoupleable
components.

Personally, I think that anything which increases the use of Avalon
compatible components will only benefit the Avalon community.

- Sam Ruby


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message