avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: limiting the scope of avalon
Date Tue, 29 Jul 2003 13:19:00 GMT
Stephen McConnell wrote:

> Berin Loritsch wrote:
>> ?!  The only things we officially have in place are ECM, Fortress, and
>> Phoenix.  It should be limited to that function set. 
> Berin:
> I would like to draw you attention to the following:
> * The excalibur-lifecycle package is released and is a part of the 
> Avalon toolkit.
> * The meta-info package is in sandbox and is certainly ready for release 
> as is.
> * The Merlin container is also ready for release.
> I don't think we should ignore our responsibilities with respect to 
> released packages, and I don't think we should promote an artificial and 
> self-serving discrimination against the contributions that exist in the 
> sandbox.

I hear you loud and clear.  However, getting back to my question about
how to manage the growth of APIs, please let me draw your attention to the

* I would like meta-info and Merlin released
* For those function areas that we have not all had time to digest, namely
   the extension meta info, I would like a breakin period.
* The rest of the meta-info standard is ready for release without any

My idea to grow the API in a controllable and sustainable way is to introduce
new ideas and concepts in a separate namespace.  I prefer a functional one as
opposed to a container specific one.  This will allow the rest of us to see
how it works with Fortress/Merlin/and possibly even Phoenix.  When the rest of
us (including me) are comfortable with the solution, we can vote to include it
in the Avalon namespace.

So far, the only side of the equation that I have asked us to change is the
meta-info gathering tool (meta-tools).  That means the rest of the entire
equation (i.e. the XML descriptors and serialized meta info) has not changed.
Those are the container contracts--and for now I am most interested in the
client contracts.  The only impact to moving the attributes back into the
avalon namespace is to have the meta-tools recognize both @avalon and
@lifecycle, issuing a deprecation warning for @lifecycle.

I really don't think that is unreasonable, do you?


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

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message