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 -- +------//-------------------+ / http://www.dpml.net / / http://niclas.hedhman.org / +------//-------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
