[Proposal] Planning for the Future

[Berin Loritsch <bl...@citi-us.com>]

Unless there is a strong objection by anyone in the
near future, it looks like the *community* has decided
to go for the unified container approach--allowing it
to be customized for whatever profile the user needs.

I think this is a healthy step forward, and we now
have a general direction to move towards.  It is also
holiday season, and we Americans are getting ready for
the Thanksgiving feast (I think everyone should have
a thanksgiving).  Also coming up are Christmas,
Hanukah, New Years Eve, etc.  This is generally not
a time for quick consensus, so we will move forward
slowly.

If there is no objection, I would like to provide a
tentative outline for the plan of attack (no dates
attached, this is Open Source after all):

1) Identify the absolute minimum requirement for Avalon
   compliance.  Currently this is be the ability to
   handle Thread Safe components (aka singleton), and
   full support for the established Avalon lifecycle.
   Beyond that, we need to come to consensus.

2) Provide a Test Suite to determine if any proposed
   Container follows the established minimum requirements.

3) Provide the implementation.  We should probably follow
   Agile practices and do the simplest thing to satisfy
   the minimum requirements.

4) Identify standard options.  Basically what additional
   "lifestyles" do we support?  How do we represent that
   in the component?  Etc.

5) Provide tests for all the standard options.

6) Provide implementation, refactoring the base code
   mercilessly until we have something that we like.

7) Identify how to implement user extensions.  These
   will be ways in which third parties like Cocoon and
   JAMES can inject domain specific functionality into
   the container.

8) Provide tests to establish if a container handles
   those extensions properly.  Also provide a way to
   extend the suite of tests so that domain specific
   functionality itself can be tested.

9) Provide the implementation for the user extensions.
   Again refactoring our code-base mercilessly until
   we have what we want--all the time making sure all
   the tests pass.

10) Identify the deployment issues like descriptors,
    packaging (if any) etc.

11) Provide the tests to ensure that the deployment
    concerns work.

12) Provide the implementation of the tools and code
    to support deployment.  Also provide the tools to
    convert existing components to the new standard.

It is important to note that some of these things will
be happening at the same time.  It is also important
to note that each of these are areas where we need to
reach consensus.  We can flesh out the details of each
stage as we get to them.  If we like this general
outline, let's put it in CVS as a POA, and we can check
off as we complete each part.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Proposal] Planning for the Future

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@citi-us.com] 
> 
> 1) Identify the absolute minimum requirement for Avalon
>    compliance.  Currently this is be the ability to
>    handle Thread Safe components (aka singleton), and
>    full support for the established Avalon lifecycle.
>    Beyond that, we need to come to consensus.

Even the lifecycle isn't 100% solid. Lately we've had some
discussions regarding the Context interface. It needs
a better definition, and we need a better interpretation
of it and understanding of just what it is.
 
I suppose this is something that will be done throughout,
though, but I'd like to get it going by step 1.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>