> -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 13, 2004 1:33 PM > To: [EMAIL PROTECTED] > Subject: Re: Technical Concerns over AF4.2 > > And we are back to the problem of knowing what we are agreeing to. > > There is no official overall Avalon X as a unified spec--this > is a gross oversight--and yet there is no listing of all the > Avalon Products that make up this "unified spec". > > Because of this, I have repeatedly asked that there be an > official Avalon X, and that Avalon framework be provided for > those who just need that part. I am in favor of an Avalon > X--but it seems as if the rest of Avalon has mixed feelings about it. > > One one hand, I am told that I should use the Avalon runtime > platform, with no idea what that really and practically > means. On the other hand I am told that there is no official > Avalon X and there is only Avalon Framework 4.2 and other > products--none of which are advertised on the site. > > So, I humbly ask you to get the story straight. Is there > really an official Avalon X with a whole working spec or is > that only marketing hype? I can't really tell. Lastly, if > there is no official Avalon X where are all the products that > make it up? They are nowhere to be found. > > This is very confusing to me (please withold any smart alec > comments). > I asked for the line in the sand so that I know what is what. > Right now, there is Merlin. That is the product. Not the > spec, the container. So in essence the spec is defined as > Merlin in all practical reality--despite the rhetoric contrariwise. > > If I agree to support Avalon Framework 4.x and 4.2 adds a new > contract I am not aware of, then we have a problem--because I > don't know about the new contract. So if I've already > committed myself to supporting framework 4.2, I have some > rework to do. The ones that don't change the code are more > of a gotcha because there is no way to easily tell from the > distribution what has changed and what is promised. >
Ok, Berin. All of these concerns you've posted here are very valid IMO. It boils down to a documentation and communication issue, and clearly (let me repeat CLEARLY) there is very little of hard documentation of what makes up the unified spec, what all that means to users/developers of components/containers, and how to proceed. Most of it is still locked away in minds with hints and roadmaps shared on the dev list. So... Your issues and concerns are valid, and I know the plan is address that. When? Well... You've been involved in OSS projects for a long time and understand as well as anyone that the *when* depends on availability of people. All I can suggest to you for your short-term roadmap is this: 1. Code against avalon-framework-api/impl v4.1.5. -OR- 2. Since avalon-framework 4.2 = 4.1.5 from an pure interface standpoint, the component contract spec indicates that 4.2 compatible containers should support constructor injection. If your container might instantiate 4.2+ components that utilize constructor injection AND you don't want to modify your container code to support this contract, then keep/advertise your container as a 4.1.x container. If none of your components utilize injection, then it's your call as to whether or not to use 4.2. Clearly, we need more documentation for component developers as to what constitutes an Avalon component and what constitutes an Avalon container. And that will be coming. But not in the very near future. So, the reality *today* is really not any different IMO of the reality of yesterday from a component contract standpoint. Each Avalon container still (in reality) has it's own component contract aside from avalon-framework. Until clear documentation and specs materialize that define these contracts, the safest thing for your container to do is stick with the 4.1.x framework as your only point compatibility. If you are talking about Fortress, what current Avalon build/runtime dependencies do you currently have? Stick with that until you have a set of spec and documentation of the container-component contract that you can feel comfortable working against. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
