Stephen McConnell wrote:
Berin Loritsch wrote:
I disagree here, and I will put the main disagreement as plainly as I possibly can:
Up until Avalon 4 the _only_ point of required compliance was the set of
contracts stated and enforced by the Framework.
The avalon-framework 4 contact is a binary contract that represents a set of interfaces and classes dealing primarily with lifecycle artifacts and lifecycle delivery mechanisms. The 4.0 version was basically the less-than-friendly Component based model. The 4.1.3 version introduced the service package and opened up Avalon to the rest of the world. The 4.2 release follows the trend established by 4.1.3 in lowering framework dependence while delivering better build integrity and runtime functionality.
I think I know better than anyone still here the history of Avalon. I
can take you back to Avalon 3, and getting to Avalon 4 was a major accomplishment. It marked the end of needless volatility and the beginning of a relatively stable API. Hence the version number increase. The version 3 of Avalon changed radically between releases and left a really bad taste in the mouth of its users. The version 4 of Avalon changed that. The important thing here is that it marked a line in the sand where we were going to be more careful about evolving the framework.
Also understand that it is the precedence for the solution I proposed.
It was its own project and very jealously guarded for good reason.
Another possible interpretation is that it was very jealously guarded because competing camps could not come to agreements on anything else. If that interpretation has any merit - one could anticipate a vibrant and exciting development of the framework within and beyond the framework 4 context taking into consideration - even embracing other essential ingredients in the overall specification of a robust, reliable and portable component model.
Please do not interpret what I say. I write simply without double-entendre or guile.
I think we are all in agreement that Avalon Framework 4.x is not in and
of itself enough for compatibility. What we are not in agreement on is what makes up an Avalon component. Since there are several people who advocate that things have "grown" beyond Framework I recommend an Avalon 5 to celebrate that. It is a very important thing. While there have been announcements that product X.Y.Z posted to mailing lists other than Avalon's, there isn't a public knowledge that 4.x includes more than Framework.
If that is the case, MAKE IT CLEAR. Until it is made publically and loudly clear at precisely what version Avalon includes more than just Framework, then Avalon is only framework with a container that has a lot of features. This has not yet been done. I recommend a sufficient version jump to make the fact even more clear.
Now we are in a place where
some people assert that not only framework but a whole host of other
things are required for an Avalon component.
Yep - your in that place because the assertion is true.
And this is supposed to give warm fuzzies? Come on.
WHEN was this made true? HOW was this made true? WHAT discussion and
VOTE has made this true? Up until know, I only see the ASSUMPTION that MERLIN IS AVALON. Until there is a factual and identifiable place where this break is made, with a public vote that sates it CLEARLY, things remain as they were.
Notice that I did not say it should not happen? I only said that it should be made painfully clear WHAT constitutes an Avalon compliant container and WHAT a component writer needs to do to make an Avalon component. Since there is all this other stuff now (since you haven't made it clear yet), I would like to know exactly what all this other stuff is.
To date I do not have a clear picture--because that picture is always moving. This is required, no its not, yes it is, well it should be but we can't convince enough people yet. But secretly it is. Come on, MAKE IT CLEAR.
This is the main point of
contention.
You need to clarify this. You have stated that the semantics backing the framework released to-date is insufficient. Presumably your referring to the overall specs related to 4.0, 4.1, 4.1.1, 4.1.2, 4.1.3 and 4.2.0 (not to mention a few other minor releases along the way).
And prior to 4.0.
Are you saying that the Avalon Community may neither claim now deliver backward compatibility as it moves forward? I would consider that to be an unwarranted restriction to the development of the framework - and I'm confident you agree with me.
I am saying that claiming that Avalon is more than framework has not been made crystal clear, when things were officially introduced has not been made clear, and how things relate. Framework is simple and easy to understand--incomplete, but easy to understand. WHEN did Avalon grow to be more than only framework--officially? You can't say 4.1.x because we had three competing containers during that time. 4.2 came out only recently, and I don't recall any major hoopla made about 4.2 including more than framework.
I want a line drawn in the sand to make it obvious. That way I can say I support Framework up to version 4.2 (assuming this is the last version that is separate from all the other stuff) and you can continue on evolving things.
The thing is that these things crept in not because of evolution to the framework but because of evolution of the containers.
So long as semantics at the level of the framework are undocumented and/or vague representations - a vacuum exists. Within that vacuum the Avalon Community is delivering a reference implementation. That reference implementation will inevitably fill in that vacuum.
So you are saying that Merlin is Avalon and there can be no compatible containers because Merlin is a moving target. There is so much cruft that you can't descern the minimal common denominator. What is it?
I'd really like to know.
I think we need to come to grips and realize that there will always be incompatibilities with Avalon 4 containers. Period. Anything more than framework compliance is a container specific feature.
IMO - absolutely not. You are calling for a termination of the A4 development effort. You assuming that other minds cannot deal with improvement while maintaining compatibility. I fundamentally disagree with this assertion.
No I am saying that if you are going to assert that Avalon is more than framework, you have to make it really clear with a new version number, identifying all the pieces that are comprised by that version number.
You can continue to maintain backward compatibility--I have no qualms with that.
If you want to make the rest of the "component platform" an official part of defining an avalon component the best and cleanest solution is to bump the major version as an obvious signal that the current suite
of APIs is Avalon 5.
This has nothing to do with the avalon-framework binary interface and the recognized rules concerning when and if you bump major and minor versions.
There are no rules. I haven't seen one example where there is a consistent set of rules applied accross the board for version incrementing.
No need for drama, no need to call people names or argue over what we are going to call methods. Just say that Avalon 5 is all of this stuff, because Avalon 4 just wasn't able to deliver on a bunch of promises.
And in the process mislead people about the evolution of the framework. Sorry - but your going to have to come up with a better *technical* argument than that.
IT IS NOT A TECHNICAL PROBLEM! Ok. Let me repeat that. IT IS NOT A TECHNICAL PROBLEM!
Are we clear now?
The way things are now, people are being misled. make it clear.
I can't think of a better way to say it. As long as the 4 version
number is in use that is my take on it. Since everyone brings up the
analogy of Java2 version 5 and Servlet 2.x, it is comparing apples and
oranges. There is a fundamental disagreement on what makes an Avalon
component and the minimum of what is necessary to make things compatible.
Where is the fundamental difference?
In both Java and Servlet increments, the old code will continue to compile and run. You just won't have newer features. THis is where you will argue that things are just like that in Avalon land, but they aren't. An Avalon component now requires non-code related items to make it work--and no where has this been made an item of at version X this is true. With both Java and Servlets a whole specification accompanies them--not so with Avalon. So what changes are there from last version? Well you can get a vague idea if you go through the change logs of a hundred miniprojects but you don't have it spelled out in black and white.
Until it is spelled out clearly and in one place, and announced to the world, things remain as they were at the last known version. So essentially we have Framework with container specific extensions.
If you want room to migrate "naturally" to a 5.0 because you are still experimenting, then I would be ok with a 4.5 is all of this stuff and this version of framework and anything before that is framework only. That way there is a sufficient enough jump in version number while you can grow your TCK (which I personally will be astounded when and *if* it ever shows up) and other improvements to the Avalon platform.
And that was intended to facilitate collaboration, mutual respect and all of the other nice warn and fluffy feelings?
It does not seem to be a priority with this team, which leads to more frustration with anyone who wants to build an Avalon compliant container. So, I will still be surprised--pleasantly so--but still surprised.
At no point has their been a clean break made where framework OFFICIALLY ceased to be the point of unification of Avalon containers and components. This needs to be done. Give it whatever version number you like (as long as it has not already been used). Just do it.
How about rethinking the scenario with the presumption that the Avalon community cares more about a complete component specifications than the framework in isolation - but the framework is an important part of that equation but not the complete equation. Consider also that the minds applied to the problems of evolution and value proposition delivery may perhaps be able to deliver more than has ever been archived in the past simply because the political barriers of the past exist only in the dustbins of history.
I make no presumptions. Either for or against Avalon and its community.
The fundamental problem is not technical, throwing code at it will not help. We need a clean break and to know exactly what makes an Avalon component an Avalon component and not a Merlin component.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
