avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Aaron Farr <fa...@apache.org>
Subject Re: Regarding The Avalon Framework
Date Thu, 08 Jul 2004 22:43:23 GMT
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message