avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: Avalon Versions
Date Mon, 12 Jul 2004 15:54:19 GMT
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 

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 

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 

>> 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 

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 

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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message