Follow-up of Re: How is responsible for avalon-framework-api and avalon-framework-impl?

[Siegfried Goeschl <si...@it20one.at>]

Hi folks,

it was quite fascinating to read the mails and wade through the mail 
archives ... :-)

+) in January I try to get  the Excalibur components up and running 
within the Fulcrum environement since no matter what I'm doing I'm 
reinventing the wheel - so I rather reinvent a small wheel

+) depending on the outcome and the response from the Turbine/Fulcrum 
folks that stuff might be added to Fulcrum. If not then it was at least 
some fun ... :-)

+) if anyone has an evening off he/she can have a look to get a Fulcrum 
component running in Excalibur

+) I can also lend a hand in settting up a page capturing available 
Avalon components

Cheers,

Siegfried Goeschl


Stephen McConnell wrote:

>  
>
>>-----Original Message-----
>>From: Siegfried Goeschl [mailto:siegfried.goeschl@it20one.at]
>>Sent: 13 December 2004 18:55
>>To: Excalibur Developers List
>>Subject: Re: How is responsible for avalon-framework-api and avalon-
>>framework-impl?
>>
>>Hi Niclas,
>>
>>your first point is beyond my comprehension ... ;-)
>>    
>>
>
>Don't worry - you'll come around.
>
>  
>
>>Moving the responsibilty to the components to be compatible with
>>multiple containers is IMHO the wrong way. 
>>    
>>
>
>Sure it is - in fact its just plain out and out stupid.
>
>  
>
>>Following my simple line of
>>thinking I assumed that looking at the context someone could determine
>>the container type (in the case of "urn:avalon:container" is
>>    
>>
>politically
>  
>
>>not feasable) and provide a little converter to setup the proper
>>context.
>>    
>>
>
>The urn defines the scope.  There were a set of standard Avalon context
>names but they are now largely academic as only one contained ever
>delivered complete support. I.e. you are forced to depend on the
>container's documentation concerning supported context entries.
>
>  
>
>>But any magic not being part of the official distribution is a
>>waste of time.
>>    
>>
>
>Yep.
>
>  
>
>>I appreciate that you are going to support AF4 contracts in Metro but
>>    
>>
>I
>  
>
>>have a hard time accepting that two libraries being the core of
>>"countless" avalon container implementations are now without a owner.
>>    
>>
>
>This vibrant and exciting community is the new owner.
>Isn't that great!
>
>  
>
>>And being a newbie it is difficult to appreciate the political
>>consideration without a stepping on everyone's toes (btw, I'm quite
>>    
>>
>good
>  
>
>>at that).
>>    
>>
>
>Don't worry - Avalon is dead (thanks to our little mate Stefano, all
>those darling little members of the board, the wonderful Avalon chair,
>and not to forget ... all the great little guys on this list who made
>that event what it was). 
>
>  
>
>>So, how to proceed from here?! 
>>    
>>
>
>You take into account the people actually contributing and doing stuff,
>you take into account their willingness to compromise on fundamentals,
>you take in account the roadmap, and you take into account the user
>community and the ability to deliver successful solutions.  Then - you
>pick a solution and you live with your decision.
>
>  
>
>>I would appreciate if Jakarta folks
>>could coordinate themselves to make the components reusable across
>>different containers. From a programming point of view this would
>>involve Fulcrum and Excalibur while Metro is following its own path.
>>    
>>
>
>Metro is going an order of magnitude further than Avalon was even
>thinking.  Today the runtime plugin for Avalon 4.2 is simply 19 classes
>that map between the Metro component model and the old Avalon spec.
>There is also a new improved component model available that is basically
>a cleanup of the spec combined with a lot more depth in terms of
>development tools, deployment and runtime infrastructure.  Metro
>delivers concurrent deployment of components that use different
>component models - so basically it's kind of like a layer of insulation
>against the real world.
>
>  
>
>>A toe stepping and un-political
>>    
>>
>
>:-)
>
>Go for it!
>
>Cheers, Steve.
>
>
>  
>
>>Siegfried Goeschl
>>
>>
>>
>>Niclas Hedhman wrote:
>>
>>    
>>
>>>On Tuesday 14 December 2004 01:03, Siegfried Goeschl wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>thinking along Avalon component reuse with different Avalon
>>>>        
>>>>
>containers
>  
>
>>>>.... who is actually making changes and release of
>>>>avalon-framework-[api|impl] nowadays?
>>>>
>>>>
>>>>        
>>>>
>>>Noone !
>>>When Avalon was operational, even changes to the documentation what
>>>constituted 4.2 container compliance in respect of constructors,
>>>      
>>>
>resulted
>  
>
>>in
>>    
>>
>>>a storm I haven't seen before. IIRC, Leo Simons even managed to prove
>>>      
>>>
>(at
>  
>
>>>least to himself) that the change in the docs would make an
>>>      
>>>
>incompatible
>  
>
>>>change to components that tried to be compatible with many
>>>      
>>>
>containers.
>  
>
>>>      
>>>
>>>>I checked out http://wiki.apache.org/avalon/AvalonContextSurvey and
>>>>        
>>>>
>this
>  
>
>>>>is the point where the various Avalon containers are really ehmm
>>>>improvable.. Each container has its own ideas about naming the
>>>>        
>>>>
>entries
>  
>
>>>>of the context and there is no "exists()" to facilitate querying the
>>>>context apart from catching the exceptions when you are plainly
>>>>        
>>>>
>wrong.
>  
>
>>>>Not a big deal but I'm just curious ....
>>>>
>>>>
>>>>        
>>>>
>>>In my personal opinion, you are absolutely right. However, it was not
>>>political feasible 6 months ago to try to make such unifications from
>>>      
>>>
>the
>  
>
>>>specifications point of view, and I don't think that has changed
>>>      
>>>
>much.
>  
>
>>>You instead end up of having to write components that works in many
>>>containers, i.e. the headache is moved to the component author
>>>      
>>>
>instead of
>  
>
>>the
>>    
>>
>>>container author.
>>>To achieve that you need to stay away from context entries and
>>>      
>>>
>service
>  
>
>>lookups
>>    
>>
>>>that are more complex than a single component by classname.
>>>
>>>The most capable of the containers, Merlin, is no longer actively
>>>      
>>>
>>developed as
>>    
>>
>>>an Avalon container. We have decided in Metro to evolve the AF4
>>>      
>>>
>contract
>  
>
>>>separately, and keep runtime compatibility against the Merlin
>>>      
>>>
>>specification.
>>    
>>
>>>Cheers
>>>Niclas
>>>
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
>>For additional commands, e-mail: dev-help@excalibur.apache.org
>>Apache Excalibur Project -- URL: http://excalibur.apache.org/
>>    
>>
>
>
>  
>


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