excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@dpml.net>
Subject RE: How is responsible for avalon-framework-api and avalon-framework-impl?
Date Mon, 13 Dec 2004 19:07:43 GMT

> -----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
> 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.


> I appreciate that you are going to support AF4 contracts in Metro but
> 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
> 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
> >>.... 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,
> in
> >a storm I haven't seen before. IIRC, Leo Simons even managed to prove
> >least to himself) that the change in the docs would make an
> >change to components that tried to be compatible with many
> >
> >
> >
> >>I checked out http://wiki.apache.org/avalon/AvalonContextSurvey and
> >>is the point where the various Avalon containers are really ehmm
> >>improvable.. Each container has its own ideas about naming the
> >>of the context and there is no "exists()" to facilitate querying the
> >>context apart from catching the exceptions when you are plainly
> >>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
> >specifications point of view, and I don't think that has changed
> >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
> 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
> >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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

View raw message