J Aaron Farr wrote:
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."
And since then we have put into concrete the single product policy and the documentation focused on the single product and the respective specifications and you can draw a line between 4.1 and 4.2 and say - here - at this point - certain semantics are supported.
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.
The Framework only makes sense within a set of assumptions concerning the semantics of component handling. I don't care what version number you want to assign the complete semantics but what I do care about is about falling into the false assumption that the framework is some kind of a product.
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?
Stop thinking about "the framework" and think about the component contract. The component contact covers the instantiation of the instance relative to a lifestyle, the population of the instance using certain lifecycle artifacts, the runtime management of the instance, and the decommissioning of the instance. This involves meta-info about the component, computational contracts defining artifacts, and semantics about the behavior of those contracts.
This isn't about re-writing history - its about filling in the blank pages.
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.
IMO 4.X compliance is largely irrelevant simply because the framework as it stands in isolation does not give you a sufficient contract. What I've describing above is probably wrong - instead of talking about "framework" we should be talking about the single product version - because its the combination of several systems that provide you with the component contract. As a minimum this include:
* framework api * meta info tags, format and packaging * lifecycle extension api
What your seeing on the web-site today is the presentation of the component model - as opposed to pieces of the picture. That difference in view point is *very* important and represents a big step forward.
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.
You can archive this by adding to the current documentation the relationship of a feature with a particular sub-system version.
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.
I honest don't know what you are referring to with the phrase "missing framework docs". Its all there. The only thing this thread is justifying (and quite reasonably) is the addition of association of features with versions. E.g.:
Since: framework api 4.3.0 Since: composition spi 2.0.0 Since: meta-api 2.0.1
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.
Not sure where you going here - but lets not get carried away. We have one product. The framework is a small part of that system. Nothing in the documentation or current implementation breaks backward compatibility with prior releases. What has changed is that multiple systems have been brought together and from that a single specification is unfolding. Within that single specification there is room for documenting semantic assumptions relative to sub-system versions. If that's what your intention is then I'm right behind you. If on the other hand your intention is to setup a separate product definition - well - that's something I would not be ok with.
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]
