> -----Original Message----- > From: Siegfried Goeschl [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Apache Excalibur Project -- URL: http://excalibur.apache.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
