You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/07/13 02:27:45 UTC
Technical Concerns over AF4.2
Gang,
I am trying to put all the "community issues" aside and distill what
are the technical objections to;
-----------------------
<issue>
AF4.2 allows component authors to request a supply of the LifeCycle
artifacts (Context, ServiceManager, Configuration) as constructor
injections instead of classic styled phased injection.
</issue>
I don't think that even LSD can concoct a case where this introduces a
component incompatibility. If there is a valid case of a 4.1 component
written which won't work with this, then we deal with it.
It also implies that AF4.2 compliant containers need a little bit
tweaking.
(Please observe that Merlin's feature of injecting just about anything
into the constructor parameters, are not part of the framework
specification.)
-------------------------------
<issue>
Concerned has been raised that Avalon Framework has lost visibility on
the new web site.
</issue>
Personally, I am willing to either place a "AF4.1" link under Central,
pointing to the old docs, or including Framework in the Products
column on the home page pointing to the relevant current section of
the component specification, i.e. LifeCycle specification and/or the
javadocs. PROVIDED, that all this hoo-haa settles down and instigation
stops from all sides (I'm glad I'm not on PMC anymore).
-------------------------------
<issue>
Avalon (Framework) compliance/compatibility
</issue>
This seems to be perceived very differently. I (and Stephen) maintains
that "Avalon 4" compliance doesn't exist, and no need to discuss it.
We should talk about "Avalon Framework 4.x" or "Avalon 4.x Lifecycle"
compliance/compatibility.
If everyone can agree on either of these terms, things are suddenly a
lot easier to handle.
I would like to propose that we setup a page (if it doesn't exist)
where the containers we know of are listed, and add columna (to start
with) for various features.
1. AF4 LifeCycle.
2. AF4 LifeCycle Artifact Constructor Injection.
We can add more columns and containers as we go along.
We can't we get along?
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Technical Concerns over AF4.2
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>>
>>> <issue>
>>> Concerned has been raised that Avalon Framework has lost visibility
>>> on the new web site.
>>> </issue>
>>>
>>> Personally, I am willing to either place a "AF4.1" link under
>>> Central, pointing to the old docs, or including Framework in the
>>> Products column on the home page pointing to the relevant current
>>> section of the component specification, i.e. LifeCycle specification
>>> and/or the javadocs. PROVIDED, that all this hoo-haa settles down and
>>> instigation stops from all sides (I'm glad I'm not on PMC anymore).
>>
>>
>> I'm ok with putting a AF4.1 link under Central. I'm not ok with
>> Framework under Products. I am also ok with updating existing docs
>> with information that clearly associates versions with sementic
>> descriptions.
>
>
> Why not Products?
First and foremost its a conflict in terminology:
* A product implements zero or more specifications, is typically
used by a user, provides certain features and benefits, and
at the end of the day represents a certain value proposition.
* A specification will typically incorporate an api and
documentation detailing semantics.
Secondly, it is in conflict with Avalon's objectives - a complete,
consistent, and portable component model and reference implementation.
Keep in mind that the framework in isolation does not define a complete,
consistent, nor portable component model. Achieving that definition
involves a bunch of other things - some that exist, some that don't. But
this project is about achieving that objective. In the process we have
the responsibility of managing a number of apis that are exposed to
users at different levels:
To the component author Avalon specifications of interest include:
* avalon-framework-api#4.2.0
* avalon-util-lifecycle#1.1.1
For developers of component based systems that leverage component
management, the area of concern expands to the following:
* avalon-util-extension-api#1.2.0
* avalon-composition-api#2.0.0
* avalon-repository-api#2.0.0
* avalon-repository-spi#2.0.0
* avalon-logging-api#1.0.0
* avalon-meta-api#1.4.0
* avalon-meta-spi#1.4.0
* avalon-logging-spi#1.0.0
* avalon-composition-spi#2.0.0
* avalon-merlin-api#3.3.0
Developers of advanced embedded systems may also leverage the Avalon
runtime activation contract:
* avalon-activation-api#2.0.0
A product is a system that provides an end-user solution that is
consistent with one or more of the specifications described above. For
example, Fortress is a product that for the time being is consistent
with avalon-framework-api#4.1.X and probably avalon-util-lifecycle#1.X.
Merlin is our reference implementation - a product that implements all
of the above specifications.
Is framework a product - no - it's just part of the specification of a
evolving component model.
Stephen.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Technical Concerns over AF4.2
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
>>
>> <issue>
>> Concerned has been raised that Avalon Framework has lost visibility on
>> the new web site.
>> </issue>
>>
>> Personally, I am willing to either place a "AF4.1" link under Central,
>> pointing to the old docs, or including Framework in the Products
>> column on the home page pointing to the relevant current section of
>> the component specification, i.e. LifeCycle specification and/or the
>> javadocs. PROVIDED, that all this hoo-haa settles down and instigation
>> stops from all sides (I'm glad I'm not on PMC anymore).
>
> I'm ok with putting a AF4.1 link under Central. I'm not ok with
> Framework under Products. I am also ok with updating existing docs with
> information that clearly associates versions with sementic descriptions.
Why not Products? Until there is a unified Avalon Planet to advertise,
maintaining the Avalon Framework product is very important to all
interested parties.
I will repeat that I have no qualms with Avalon Planet, or
de-emphasizing framework. I do have a problem with the way it is being
done. This is why I have kept pressing for a clean break where the
Avalon team can say that the line has been drawn and this is where we
emphasize Avalon Planet.
The onus here is that the Avalon Planet would supercede Framework by
itself. Until that is done, I believe it is critical that Framework
continues to be a visible product of Avalon.
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Technical Concerns over AF4.2
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>
> Gang,
>
> I am trying to put all the "community issues" aside and distill what are
> the technical objections to;
>
> -----------------------
>
> <issue>
> AF4.2 allows component authors to request a supply of the LifeCycle
> artifacts (Context, ServiceManager, Configuration) as constructor
> injections instead of classic styled phased injection.
> </issue>
Just a minor point ..
s/instead/in preference to
> I don't think that even LSD can concoct a case where this introduces a
> component incompatibility. If there is a valid case of a 4.1 component
> written which won't work with this, then we deal with it.
>
> It also implies that AF4.2 compliant containers need a little bit tweaking.
>
> (Please observe that Merlin's feature of injecting just about anything
> into the constructor parameters, are not part of the framework
> specification.)
>
> -------------------------------
>
> <issue>
> Concerned has been raised that Avalon Framework has lost visibility on
> the new web site.
> </issue>
>
> Personally, I am willing to either place a "AF4.1" link under Central,
> pointing to the old docs, or including Framework in the Products column
> on the home page pointing to the relevant current section of the
> component specification, i.e. LifeCycle specification and/or the
> javadocs. PROVIDED, that all this hoo-haa settles down and instigation
> stops from all sides (I'm glad I'm not on PMC anymore).
I'm ok with putting a AF4.1 link under Central. I'm not ok with
Framework under Products. I am also ok with updating existing docs with
information that clearly associates versions with sementic descriptions.
Cheers, Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Technical Concerns over AF4.2
Posted by Niclas Hedhman <ni...@hedhman.org>.
Elsewhere, one more valid technical concern was concluded;
<issue>
Avalon Framework 4.2 (4.2.1 I guess) should have instantiation support
for the new container requirement, i.e. LifeCycle artifact injection
in constructor.
</issue>
I am in favour of putting this in place asap, to help out the
container authors to become 4.2 compliant.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org