avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: [OT] Jakarta: keeping track of it all
Date Thu, 02 May 2002 13:04:43 GMT
On Thu, May 02, 2002 at 02:16:41PM +0200, Leo Simons wrote:
> > ls jakarta-avalon-excalibur
> > ls jakarta-commons
> > ls jakarta-commons-sandbox
> > 
> > Eek! Look at all those suspiciously similar packages. io, cli, store,
> > utils, configuration, database conn pool, threading, logging. I don't
> > think we Excalibur developers should claim the moral high ground on the
> > code duplication issue ;P
> the sole reason we still have excalibur and cornerstone is that the
> commons project will not accept avalon-enabled components.

According to dependencies.txt, we've got 14 Excalibur subprojects
independent of Avalon.

Some reasons I think they're not in Commons:

1) Pete, Berin and other code authors (who usually do code maintenance)
   don't want to subscribe to another list with lots of
   unrelated-to-avalon chatter.
2) Commons "governance" is a bit whacked. Anyone can vote on components
   they know and care nothing about. Regularly, committers are expected
   to vote on things they know nothing about. 
3) Some Avalon people have a severe conspiracy theory streak, and
   believe that anyone not "for" IoC and Avalon is either stupid,
   insane, or simply out to get us.. <twitch> ;)

> I'd be happy if they would, we'd just migrate everything over to
> commons, make all of avalon committers to commons, then start work on
> integrating (taking the best pieces of the various implementations and
> "avalonabling" all of it).
> The way I see it, Avalon Framework should be in very widespread use
> across the Jakarta and XML projects.

"should" is a word that sets off warning bells. Who's to judge what
people should spend their free time doing?

> The way we capture complex design issues in a small, solid framework
> is not found in any of the other projects.
> Commons doesn't see it that way and feels any component that uses the
> avalon framework interfaces as having an ugly dependency on some
> external project.

Not an ugly dependency, just *a* dependency. If it's got a dep on an
external project, that rather limits it's reusability, defeating the
point of it being in Commons.


> This is a shame. I will keep claiming that moral high ground tho! ;)
> cheers,
> - Leo

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

View raw message