avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: What is Avalon?
Date Fri, 21 Jun 2002 15:50:29 GMT

                      |  ------ Utility classes
                    /   \
                   /  |  \
           Reference implementations
              |  |  |  |  |  |  |
       Applications tha work in the above

That is (with current stuff):

                      |  ------ Excalibur
                    /   \
                   /  |  \
Phoenix,  Fortress, Merlin, Jesktop (yes, Jesktop)
             |  |  |  |  |  |  |
    Cornerstone, Phoenix Apps, Jesktop Apps

IE (what I'd *strive* to do)

                   | ------ Excalibur Fortress+Merlin+containerkit
          |  |  |  |  |  |  |
  Cornerstone, Phoenix Apps, Turbine services

The first step of all this is moving excalibur stuff in commons, as we 
are currently doing.
In the meantime, finish the discussion about what we can do to make only 
*one* framework implementation reference, based on Containerkit, 
Fortress and Merlin.
If one size doesn't fit all, we will never go ahead ATM.
Finally concentrate on Phoenix and make it a real server killer app.

Currently on the Tomcat list they are starting to discuss about Tomcat 
5. This is a snippet about using Avalon in Tomcat.

Please read carefully, this is how we are seen from the outside.
No wonder Jason took so long before starting to use Avalon... we should 
stop for now to be only design freaks and start the real stuff.

Nicola Ken Barozzi wrote:

 >>>>What about using Avalon as a framework?
 >>>>This way we would have a unified server environment,
 >>>>and reusable server components.

Remy Maucherat wrote:

 >>>(I'm tired of replying to this)
 >>>Avalon is the contrary of flexibility, so it will not
 >>> be considered (at least not by me).

Pier Fumagalli wrote:

 >> That's a JOKE right?

"Remy Maucherat" <remm@apache.org> wrote:

 >Ok, so maybe my statement was too strong ;-)
 > For all the things it gives you, Avalon is a framework, and makes
 > you feel like it. It imposes contracts between
 > components / patterns, packaging, etc. All things which aren't
 > compatible with 5.0. And more importantly, the API changes
 > often, to the extent that all the projects which use Avalon
 > work off a specific snapshot, and don't upgrade too often.
 > Also, most of the utility provided by Avalon are available from
 > the commons without any string attached, and/or are of a better
 > quality.
 > There has been plenty of discussion on that with Paul, and during
 > the whole commons-logging incident, at which point I thought it
 > would be best if I didn't have anything to do with Avalon.
 > OTOH, we could have optional Avalon wrappers again, as long
 > as there is someone to write them *and* maintain them when
 > the API changes. So +0.1 to work nice with Avalon, but -1
 > for basing the architecture on Avalon.
 > Remy

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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