avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Jakarta Newsletter
Date Thu, 27 Jun 2002 17:00:44 GMT
> From: Rob Oxspring [mailto:roxspring@imapmail.org] 

> What I'm after is a volunteer from each group to edit together
> of the intersting / important discussions within their own group over
> course of June, and send me the result by the end of Sunday.  It would
> good (though not essential) if you could let me know that someone will
> taking on the task for your project, so that I can reduce the general
> pestering in later mails .  Any groups that submit nothing will simply
> feature as I have not got the time to browse and edit the discussions

Rob, we at the Avalon group have just the thing for you since we are at
point where we want to gather user feedback.

The Avalon team is in the process of identifying the requirements for a
version of the Avalon Framework.  The changes are minimal, and focus on
tighter definition of the contract between the container and the
The container is the code that manages all the components and how to
them.  The Avalon team has identified some anti-patterns related to its
and wants to provide a way to make it easier to use correctly.

What we want to find out from the community at large is:

1) Are you currently using Avalon in one of your projects?
2) If not, what would it take for you to consider using it on a future
3) If yes, what did you like best?
   What were your greatest challenges?
   If you could choose one way to improve Avalon, what would it be?

I'm not sure how we want to handle the communication.  If they post
comments to avalon-users@jakarta.apache.org I can moderate them through.
The development team reads that list.

Slated for the next version of Avalon already:

1) Enhanced Meta Data.  We are unifying the way we define meta data for
   the components.  This allows the component to be used in any Avalon
   compliant container with zero issues.  Previously you had to find out
   how any one container defined meta information (like version, whether
   the component is threadsafe or not, etc.).

2) (Tentative but likely) Standard way of extending the component
   Avalon already has a rich lifecycle management system, but sometimes
   you need an application specific extension.  We have plans of
   that to happen, and use any of the existing containers.

3) Enhanced tutuorials, user documentation.  The new docs (when written)
   focus first on how to use Avalon (the biggest complaint about our
   It will then present the anti-patterns that Avalon is supposed to
   and the patterns it uses to solve those issues.

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