Avaloners,
There has been some controversy about the status of framework documentation under the new site. I'm hoping to clarify everything in this email without starting any flame-wars.
:-)
Well - let's qualify controversy - Leo posted a interesting message to the PMC with a veto with respect to the current documentation concerning component incarnation. Leo also included a set of technical claims that I happen to disagree with. I've asked for clarification of the validity of Leo's veto on the PMC list and pending further information I'm not planning on taking any action with respect to Leo's veto. I've also asked Leo to post his issue directly to the dev list where technical discussion belongs.
Both requests remain open.
Several individuals including myself have expressed some concerns that can be summarized as follows:
The Avalon Framework documentation has been removed and what is left
is (buried) under the component specification section. Moreover, the
documentation refers to Merlin-specific features of the Avalon
framework such as constructor dependency injection [1].
The is no such thing as "Merlin-specific". Merlin is the Avalon reference implementation. I.e. constructor injection of lifecycle artifacts - introduced with the release of 4.2 is part of the Avalon Framework 4.2 contract. The only difference between 4.1 and 4.2 is that the semantics concerning object instantiation are now documented. I should also point out that 4.2 remains 100% backward compatible with 4.1.
This can cause confusion for users of other Avalon-based containers and platforms.
I am of the opposite position. Actually documenting semantics as opposed to presumption of semantics eliminates confusion. If you take a look at so called "Avalon-based" containers you will find many incompatible variations due to the lack of strict semantic specifications. However - these containers can claim compliance with Avalon 4.1. To claim compliance with 4.2 a container must me a lot more rigorous about its handling of components. I expect this trend to continue as we move forward with 4.3 and 5.0. I also expect the relevance of "framework" to shrink and more people become aware of the more complete picture presented by a combination of framework interfaces and component meta-info.
With that out of the way, let's look at what we can do to rectify the situation.
Avalon's Stewardship ====================
Avalon has developed over the years to provide a complete platform for container development. That includes many things above and beyond the simple Avalon framework which has always been the core of this project.
At the same time Avalon has aimed to provide not only a complete platform but a _common_ platform for others to use in developing similar container technologies. Avalon has been entrusted with the stewardship of that core framework which as imperfect as it is is widely used in and out of Avalon and Apache. For this very reason changes to the framework API have involved a careful and often laborious process.
Let's not fall into a trap here.
The framework is part of the the client component contract. Does your usage of the word "framework" encompass the javadoc tags, meta-info, lookup semantics, context entry management, etc. - or does you notion of "framework" fall into the category "anything goes". My point here is that up to and including framework 4.1. its been fair game for anyone to use and abuse the "framework". But (IMVHO) that's historical. Times are changing and we are moving steadily toward stronger contracts and higher overall integrity.
It is inevitable that the framework will evolve to support new features and enhancements such as new forms of dependency injection. Consequently, it will be the responsibility of developers who have written Avalon-based projects to "keep up" if they so desire. However, we need to ensure that such evolution occurs in a responsible manner by using strict versioning controls and providing historic and clear documentation.
Not a problem.
Prior to framework 4.2 the semantics attributed to the instantiation of a component and its constructor have not been documented and have been largely assumed as a null constructor.
Under 4.2 this has been clarified. The inclusion of the above paragraph is sufficient in terms of information concerning constructor management. Equivalent paragraphs are required on things related to lookup semantics and context entry semantics, etc. etc.. This will not change in the future - we will have facilities assuming composition 2.0 or the logging management api 1.0. Framework is not a special case. What is significant is the need to express an assumption.
The Nice Thing About Standards ==============================
"The nice thing about standards is that there are so many of them to choose from." --Andrew S. Tanenbaum
We need to discover a way to balance support for older Avalon flavors while still allowing the Avalon framework the ability to grow and change. Thankfully, that's not too hard. Here is my suggestion which is open for discussion:
1. Create a section in the site dedicated to the pure and simple Avalon framework This section may be under "Systems" [2] or might be a product right beside Merlin Runtime (I'm favoring product more myself).
-1
Unnecessary and confusing. All we need is to qualify semantics relative to versions of the framework and other sub-system apis (such as composition).
Instead - I think we should be considering how to express within meta-info the assumptions that a component is making. For example - let a component declare that it assumes a particular deployment environment. We are already faced with this requirement with some of our facilities - for example a http message aware component should be able to declare the presumption that an http facility as a prerequisite (but not a structural dependency).
2. This framework section will document a series of Avalon framework specifications for each version of the Avalon 4 series. This includes API docs, examples, and discussion of various "optional" contracts which have been included in some containers.
I think it is much better to qualify features against subsystem version. Keep things under a single specification ...
@since 4.2 etc.
Cheers, Steve.
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
