avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: lifecycle extension checklist
Date Tue, 29 Jul 2003 13:29:39 GMT
Stephen McConnell wrote:

> 
> 
> Berin Loritsch wrote:
> 
>> Stephen McConnell wrote:
>>
>>> Extensions became intrinsic to the component deployment model when we 
>>> voted for the release of the excalibur-extension package (a vote that 
>>> received your +1).  At that point we said to everyone out there that 
>>> there is a notion of lifecycle stage extensions in Avalon.  We 
>>> documented in that release the support for that abstraction in both 
>>> Merlin and Fortress.  There are simply no issues to solve - this is 
>>> simply a matter of getting back to a process of collaboration.
>>
>>
>>
>> I don't buy that reasoning.  Lifecycle extensions (as released) are a 
>> set of interfaces.  Those interfaces work.  Currently Fortress and 
>> Merlin have two different ways of addressing how to work with them.  I 
>> don't think you have been listening to the points I have been raising 
>> either. 
> 
> 
> 
> Could you please take a moment to detail any problems you see concerning 
> stage management.  I have (on at least two occuations) offered to assist 
> you on this subjet and remain willing to help you out on this.  Perhaps 
> we can nail down you technical concerns once and for all.


Here they are (mostly related to growing the API):

* First, when growing an API we need to get everyone on board so that they
   understand what that API is doing.

* Second, we need a way for users to be able to play with the new functionality
   without being lulled into thinking everyone is on board with it.  While the
   Avalon namespace does imply that, IMO is should only be used for pure Avalon
   components.

* Third, I believe that we should embrace a multi-namespace world (we will have
   to for management extensions).  This could lay the foundation for container
   extensions which in turn would encourage users to embrace tags not specified
   in the Avalon namespace.  Esp. when it doesn't matter what container they
   use, they can still keep the same functionality.

* Fourth, in my mind the stage/extension stuff is a risk due to the general lack
   of knowledge with it.  While I do want to understand it, that takes time, and
   I would rather have a release of Meta-info now so we can start integrating the
   libraries.

* Lastly, we need to manage user expectation.  I have a project that will be
   using the lifecycle extensions, so it is of great interest to me.  It will
   also help me to understand what I do and don't like about the way it is now.
   Until such a time, I really don't feel comfortable signing off on them being
   in the Avalon namespace.

Please see my response to the other email so that you can see a few further
arguments.

Please understand that I am not ignoring your oppinions at all, but I am trying
to get you to recognize the value in my oppinions.


-- 

"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


Mime
View raw message