[prev in list] [next in list] [prev in thread] [next in thread] 

List:       avalon-dev
Subject:    RE: Jakarta Newsletter
From:       "Berin Loritsch" <bloritsch () apache ! org>
Date:       2002-06-27 17:00:44
[Download RAW message or body]

> From: Rob Oxspring [mailto:roxspring@imapmail.org] 

> What I'm after is a volunteer from each group to edit together
summaries
> of the intersting / important discussions within their own group over
the
> course of June, and send me the result by the end of Sunday.  It would
be
> good (though not essential) if you could let me know that someone will
be
> 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
not
> feature as I have not got the time to browse and edit the discussions
myself.

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

The Avalon team is in the process of identifying the requirements for a
new
version of the Avalon Framework.  The changes are minimal, and focus on
a
tighter definition of the contract between the container and the
component.
The container is the code that manages all the components and how to
access
them.  The Avalon team has identified some anti-patterns related to its
use,
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
project?
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
their
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
lifecycle.
   Avalon already has a rich lifecycle management system, but sometimes
   you need an application specific extension.  We have plans of
allowing
   that to happen, and use any of the existing containers.

3) Enhanced tutuorials, user documentation.  The new docs (when written)
will
   focus first on how to use Avalon (the biggest complaint about our
documentation).
   It will then present the anti-patterns that Avalon is supposed to
address,
   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>

[prev in list] [next in list] [prev in thread] [next in thread]