Sam Ruby wrote:

Berin Loritsch wrote:

I have a feeling when all is said and done we will have the following
distributions:

excalibur-component.jar (container, component, logmanager)
excalibur-datasource.jar
excalibur-xml.jar (xpath, parser, xslt object, etc.)
excalibur-url.jar (source, resource, etc.)
excalibur-async.jar (monitor, event, etc.)


Don't forget clutil.

My two cents: if you have componentry which you are willing to split out
that does not have significant dependencies on any particular framework, it
will likely get greater visibility and usage if it is in either
jakarta-commons or xml-commons.

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.


I really don't feel Avalon Framework is all that binding--and it encourages

good practices.  I would prefer seeing well behaved Components designed for
Avalon, than ones that are patched together with bail, wire, and duct tape.

The reason we want to break Excalibur into smaller swords is so that more
narrowly defined projects can take advantage of what they want without the
extra stuff they don't want.  Excalibur isn't necessarily an Avalon Commons,
although there is a little bit of that evident.

There are however a number of utilities that would be easily placed in Commons.
The following packages do not have direct ties to Avalon:

cli (Command Line Interface)
collections (Buffer and other utilities)
concurrent (semaphores, mutexes, etc.)
io (file, stream, and other IO utilities)
pool (pool interfaces and implementations)
event (event queues--scratchpad)
profile (intrumentation of code--scratchpad)
vfs (virtual file system--scratchpad)
thread (thread pool--scratchpad, dependant on pool)
util (various utility classes--scratchpad)
i18n (ResourceBundle utilities, and an XMLResourceBundle in scratchpad)


Those are the only things I can see _possibly_ moving in that direction.

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.

Some things like CLI might make a good contribution, and someone may really
improve the internal architecture, and parameter parsing capabilities (i.e.
make it able to interpret GNU style parameters, POV-Ray style parameters, etc).

The problem is that if the interfaces change, that change will affect a number
of different projects: Phoenix, Cocoon, Axis, and JAMES to name a few.

I would like to get the concensus of the Avalon team before considering
such a move.  That move will change the package names (allowing us to get
rid of cruft and remove deprecated methods and classes in the process).

Here are the issues I see with this move:

1) I personally don't have the energy/time to support yet another project,
   but I can support these utilities where they are now.
2) I already receive over 125 emails between 5:00pm and 8:30am the next
   morning due to the mailing lists I subscribe to.  Another list with all
   the associated noise is not really feasible.
3) These utilities could possibly die in commons, where they would survive
   in Avalon.
4) Commons could so tightly integrate the utilities that they no longer
   able to be used without additional cruft we have no interest in.

Admittedly, some of these are FUD on my part, but they are real concerns that
I have, and they need to be allayed before I can support a decision to move
Avalon code outside of Avalon.  All the other pieces are either Avalon 
Components,
or support the Avalon architecture, so they will never be considered for
integration with Commons.

--

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


-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



Reply via email to