You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Siegfried Goeschl <si...@it20one.at> on 2004/12/13 18:03:41 UTC
How is responsible for avalon-framework-api and avalon-framework-impl?
Hi folks,
thinking along Avalon component reuse with different Avalon containers
.... who is actually making changes and release of
avalon-framework-[api|impl] nowadays?
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 ....
Thanks in advance
Siegfried Goeschl
PS: Maybe I have to implement something like a "Container Personality"
(the term is nicked from Plexus) to provide the correct context for
Fulcrum-YAAFI ... :-(
---------------------------------------------------------------------
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/
Re: How is responsible for avalon-framework-api and avalon-framework-impl?
Posted by Leo Simons <ls...@jicarilla.org>.
Siegfried Goeschl wrote:
> Hi folks,
Hi Sigfried!
> thinking along Avalon component reuse with different Avalon containers
> .... who is actually making changes and release of
> avalon-framework-[api|impl] nowadays?
The excalibur project; the bleeding edge of the code is in excalibur SVN
under trunk/framework. Note that avalon-framework tends to be mostly in
a "bugfix" mode. Making big changes at this point is likely to just
result in less compatibility between the various container solutions out
there.
> I checked out http://wiki.apache.org/avalon/AvalonContextSurvey and this
> is the point where the various Avalon containers are really ehmm
> improvable.
yep. We spent a lot of time thinking about that. In the end, no change
was made. I forgot most of that discussion, it's in the dev@avalon
archives, no doubt.
> 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 a fully IOC application (IOC in the way avalon originally specified
it, not as is in common use now ie dependency injection), exists() is a
bad idea. The container is responsible for making sure that either the
component has everything it needs (which the component author can
specify using "metadata") and if it cannot do that it shouldn't load the
component at all.
In other words, there are no "optional dependencies" on context information.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: How is responsible for avalon-framework-api and avalon-framework-impl?
Posted by Leo Simons <ls...@jicarilla.org>.
Siegfried Goeschl wrote:
> Hi folks,
Hi Sigfried!
> thinking along Avalon component reuse with different Avalon containers
> .... who is actually making changes and release of
> avalon-framework-[api|impl] nowadays?
The excalibur project; the bleeding edge of the code is in excalibur SVN
under trunk/framework. Note that avalon-framework tends to be mostly in
a "bugfix" mode. Making big changes at this point is likely to just
result in less compatibility between the various container solutions out
there.
> I checked out http://wiki.apache.org/avalon/AvalonContextSurvey and this
> is the point where the various Avalon containers are really ehmm
> improvable.
yep. We spent a lot of time thinking about that. In the end, no change
was made. I forgot most of that discussion, it's in the dev@avalon
archives, no doubt.
> 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 a fully IOC application (IOC in the way avalon originally specified
it, not as is in common use now ie dependency injection), exists() is a
bad idea. The container is responsible for making sure that either the
component has everything it needs (which the component author can
specify using "metadata") and if it cannot do that it shouldn't load the
component at all.
In other words, there are no "optional dependencies" on context information.
cheers,
- Leo
---------------------------------------------------------------------
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/
Follow-up of Re: How is responsible for avalon-framework-api and
avalon-framework-impl?
Posted by 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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Follow-up of Re: How is responsible for avalon-framework-api and
avalon-framework-impl?
Posted by 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
RE: How is responsible for avalon-framework-api and avalon-framework-impl?
Posted by Stephen McConnell <mc...@dpml.net>.
> -----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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: How is responsible for avalon-framework-api and avalon-framework-impl?
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Niclas,
your first point is beyond my comprehension ... ;-)
Moving the responsibilty to the components to be compatible with
multiple containers is IMHO the wrong way. 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. 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 I
have a hard time accepting that two libraries being the core of
"countless" avalon container implementations are now without a owner.
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).
So, how to proceed from here?! - 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.
A toe stepping and un-political
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/
Re: How is responsible for avalon-framework-api and avalon-framework-impl?
Posted by Niclas Hedhman <ni...@hedhman.org>.
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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/