Stephen McConnell wrote:
Both requests remain open.
I am not concerned with Leo's "veto" at the moment. While I have not discussed this with him I believe my proposal on framework documentation will go a long way to resolving his concerns.
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 is not correct.
Release 4.2.0 of the Avalon framework as presented in the vote and release did not mention constructor injection. see:
http://marc.theaimsgroup.com/?l=avalon-dev&m=108324047317944&w=2
http://marc.theaimsgroup.com/?l=avalon-users&m=108415482904649&w=2
Constructor injection *was* mentioned in respect to Merlin 3.3.0 which happened to be released at the same time:
http://marc.theaimsgroup.com/?l=avalon-dev&m=108032811015526&w=2
It was also mentioned in the proposal for Merlin constructor injection in this post:
http://marc.theaimsgroup.com/?l=avalon-dev&m=107908355100216&w=2
At the time you wrote:
"Like I said - its about getting some usage and exposure before potentially pushing such a thing into the framework."
However, at no point do I remember a discussion about moving this feature from Merlin into the Framework. If you intended the changes to be true to all Framework 4.2.0 compliant containers then that should have (1) been included in release notes specific to the Framework release and (2) explicitly mentioned in a separate post to alert those not following all Merlin specific development.
Now, on its own merits the constructor injection feature is a Good Thing. But is was added and presented as a feature enhancement to Merlin only and not a requirement to be added into the Avalon Framework contracts. Let's not re-write history here, okay?
This is exactly the same manuvering which brought about so much controversy around the meta specifications. It's not that meta itself or constructor injection is bad. What is bad is slipping it in as a Merlin feature and then extending claims of that functionality as universal to all things Avalon. It is a typical "embrace and extend" method which has brought Microsoft so much developer ire.
And before you start arguing that Merlin is THE reference implementation, please be aware that despite that label we have a responsibility to other Avalon users. We need to clearly specify Avalon component contracts, have them clearly versioned and marked, and not slip things in without weighing the impact of other Avalon clients.
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.
That is my goal. For example, apparently there is misunderstanding of what 4.2 compliance means. The documentation I am interested would specify 4.1 AND 4.2 compliance including documenting the various "optional" features.
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.
My usage of the word "framework" implies first and foremost the avalon-framework.jar code and how to use it. The matters of javadoc tags, meta-info, lookup semantics, etc. were not defined during 4.1 and I want to document that fact. I want to record the various popular was the framework was used. Yes, it is historic. No, that doesn't mean we can forget about it or throw it away.
I think it is much better to qualify features against subsystem version. Keep things under a single specification ...
@since 4.2 etc.
I want 4.1 docs online. And I'm not the only one.
Moreover I think there is a need to clarify by *consensus* 4.2 specifications because there is obviously some confusion.
Closing points:
I didn't notice the missing framework docs until just a minute or two before we launched the site. I made the mistake of underestimating the resistence I would face in correcting things. I didn't think there would be resistance. If I had known, I would have VETOED the release.
Moreover, let me make this other point very clear:
Becoming a part of Avalon means you take on *all* of Avalon, including its legacy and the support and trust of its users. That doesn't mean you have to like the old code, use the old code, or even support the old code yourself. But do not interfere with those who are donating their own free time to support those users. If you don't want to deal with the legacy, start a SourceForge project. Nobody will stop you.
jaaron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
