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

[Siegfried Goeschl]

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:[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/