avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [ANTI-VOTE] Lifecycle Extension Tags
Date Mon, 28 Jul 2003 17:45:10 GMT


Leo Sutic wrote:

>  
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org] 
>>
>>* moving out of core means death to the idea of reliable deployment 
>>across containers
>>    
>>
>
>I think your social observations are spot-on, and your technical 
>assessment is correct. The absence of the tag in the avalon
>namespace makes it optional, and thus people will ignore it.
>The absence also makes it impossible to guarantee that a component
>will run in any Avalon container.
>

Yes... that's the crux of the situation.

>
>
>But I think your summary is way off.
>
>It is not the death of cross-container deployment. We will get 
>there. Is it the death of Fortress/Merlin-style extensions? Maybe.
>

Consider that Merlin will not discontinue the use of extensions 
semantics - in fact if anything it will embrace these semantics at 
increasing more sophisticated and interesting ways.  This means that 
Merlin will continue on a path that is deferent from the rest of Avalon 
- just as Phoenix and ECM split in two directions.  What is important to 
recognize is that today this is a hair-line fracture - we can choose to 
recognize and resolve that fracture or we can choose to ignore it.  In 
my opinion - this little hair-line fracture will grow and we will see 
real divergence.  It will mean that Merlin will focus on providing a 
solution platform - not for Avalon components - but for Merlin 
components.  Why, because is users follow Merlin rules they will be safe 
and if users follow Avalon rules they do so at their own risk.

>
>I don't think the current extension model should go into the
>core, because I don't think it satisfies all needs. 
>

I agree that excalibur-extension should not go into core. 
I do not agree that the notion of deplyment phase depedencies can be 
considered non-core.


>Peter Donald
>explained some difficulties with it - mostly it didn't support
>interceptors, which I have tried, used and found very helpful
>since then.
>

Keep in mind that this is not about excalibur-lifecycle - its about the 
notion of deployment dependencies as peers to runtime dependencies.

>>* an absence of an extension mechanism in @avalon core makes the 
>>  proposal technically invalid
>>    
>>
>
>I don't understand this.
>
>All the proposal says is this:
>
>    Put the extension stuff into @lifecycle, not @avalon, because,
>    well, we just don't know whether this type of extensions will
>    be the final version.
>
>In what way is the proposal invalid?
>

The subject is about a set of tags that describe the requirements a 
container has to fulfil for reliable and predictable component 
deployment. To achieve that we must either (a) provide a complete model, 
or (b) provide a model extension mechanism.  One of the options 
described in the vote will only result in division and failure to 
achieve the objective.  As such the vote calls for unification but 
presents a solution that will divide. Hopefully a majority of people 
will figure out that this vote is premature and that perhaps there are 
some important and unresolved issues to be addressed.  If not, I guess 
its history repeating itself.

Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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


Mime
View raw message