You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@gmail.com> on 2004/07/12 10:37:41 UTC
Avalon Versions
All,
I've been following the latest threads, and just thought I'd jump in
with two small comments.
= 4.2 vs. 5 =
Some have said that "of course 4.2 is incompatible with 4.1, you don't
expect to use nio in a Java 1.3 environment, or a 2.3 servlet in a 2.2
environment, do you?".
Which is correct. If the minor version number increases, you can
expect backwards compatibility for clients, but of course not for
providers. But we're all in the business of developing providers.
Which is why versioning in Avalon-land is perceived a bit different.
A minor version change in framework is, for example, if you add a
method to ExceptionUtils. The general opinion, as I remember it, is
that a component-container contract change is a *major* version
change. The fact that Serviceable/ServiceManager was a minor change
should be written up as an exception.
Above all, since contract changes impact container developers, they
should be made in consensus with the most important container
developers (Merlin team, Excalibur, Cocoon, etc.)
Since there is no reasonable way of fixing the underspecification of
the 4.x versions without altering the framework, I think Niclas,
Stephen et al should switch to Avalon *5*, and just start cutting
cruft left, right and center. You know you'll end up with a better
result that way. *And* it will give you the room you need to
experiment.
= Constructor Injection =
The null constructor/constructor with parameters issue is easily
solvable, just thought I'd state the obvious in writing here:
A component may use either constructor dependency injection,
bean-style dependency injection, or ServiceManager lookup dependency
resolution.
Then define the requirements for each one separately.
Then define how the container will react when a component has both a
null constructor and one with parameters:
The container will first see if there is a constructor that takes any
parameters. If it finds one, it will shoot up the component according
to <<reference to constructor injection lifecycle>>. If not, it will
scan the methods for methods with signature setX (X x), where X *may*
be a dependency (absence of meta makes this a bit of hit-and-miss). If
ti finds any, it will <<blah blah blah>>...
And so on...
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>> Berin Loritsch wrote:
>>>>
>>>>
>>>>> IT IS NOT A TECHNICAL PROBLEM!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Good.
>>>> We don't have a problem.
>>>> End of thread.
>>>> Steve.
>>>
>>>
>>>
>>>
>>> Technical problems are not the only kind of problem this community
>>> needs to address.
>>>
>>> The thread is not over.
>>>
>>> Please respond to the points I made.
>>
>>
>>
>> Sorry - why should I respond to a non-technical issue?
>
>
> Ok, nevermind. Skrew your users and keep them guessing about what
> Avalon really is. Keep it up, let Avalon go into relative obscurity
> mainly because they have lost touch with one of the main reasons for
> being--people who use and support the project.
>
> After all, you can't play nice, so why play?
OK - I can live with that.
Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Niclas Hedhman <ni...@hedhman.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>> Berin Loritsch wrote:
>>>>
>>>>
>>>>> IT IS NOT A TECHNICAL PROBLEM!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Good.
>>>> We don't have a problem.
>>>> End of thread.
>>>> Steve.
>>>
>>>
>>>
>>>
>>> Technical problems are not the only kind of problem this community
>>> needs to address.
>>>
>>> The thread is not over.
>>>
>>> Please respond to the points I made.
>>
>>
>>
>> Sorry - why should I respond to a non-technical issue?
>
>
> Ok, nevermind. Skrew your users and keep them guessing about what
> Avalon really is. Keep it up, let Avalon go into relative obscurity
> mainly because they have lost touch with one of the main reasons for
> being--people who use and support the project.
>
> After all, you can't play nice, so why play?
Berin,
out of all the people taking part in this mudsling, you are IMNSHO the
person who try the hardest to make it into a Personal issue.
I kindly ask you to cool down a bit and try to view the technical
issues at hand, not whether you like Stephen or not (which we all know
already).
Where is the technical problem between AF v4.1.5 and v4.2?
1. No change in the AF code itself.
2. A Specification Clarification that 4.2 components can declare the
Life cycle artifacts in their constructor, instead of the phased
population. Containers that does not support this feature, will not be
considered 4.2 compatible.
3. All 4.1.x components will work in 4.1.x and 4.2 compliant containers.
4. Avalon is saying to its users; "Framework is NOT enough to declare
a compatible component contract. Containers SHOULD go beyond
Framework, and Avalon is providing the tools." You are free to use or
ignore this recommendation.
5. The roadmap will be pointing to an Avalon 5, which will REQUIRE
containers to support a water tight component contract, and not free
to introduce incompatibilities in the component-side contract, but
free to add extensions elsewhere. Hence the introduction of a
"Facility" concept in Merlin to make the distinction clear.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>> Berin Loritsch wrote:
>>>
>>>
>>>> IT IS NOT A TECHNICAL PROBLEM!
>>>
>>>
>>>
>>>
>>> Good.
>>> We don't have a problem.
>>> End of thread.
>>> Steve.
>>
>>
>>
>> Technical problems are not the only kind of problem this community
>> needs to address.
>>
>> The thread is not over.
>>
>> Please respond to the points I made.
>
>
> Sorry - why should I respond to a non-technical issue?
Ok, nevermind. Skrew your users and keep them guessing about what
Avalon really is. Keep it up, let Avalon go into relative obscurity
mainly because they have lost touch with one of the main reasons for
being--people who use and support the project.
After all, you can't play nice, so why play?
--
"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
Re: Avalon Versions
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>
>>> IT IS NOT A TECHNICAL PROBLEM!
>>
>>
>>
>> Good.
>> We don't have a problem.
>> End of thread.
>> Steve.
>
>
> Technical problems are not the only kind of problem this community needs
> to address.
>
> The thread is not over.
>
> Please respond to the points I made.
Sorry - why should I respond to a non-technical issue?
Stephen.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>
>> IT IS NOT A TECHNICAL PROBLEM!
>
>
> Good.
> We don't have a problem.
> End of thread.
> Steve.
Technical problems are not the only kind of problem this community needs
to address.
The thread is not over.
Please respond to the points I made.
--
"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
Re: Avalon Versions
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> IT IS NOT A TECHNICAL PROBLEM!
Good.
We don't have a problem.
End of thread.
Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Berin Loritsch <bl...@d-haven.org>.
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>> Can someone please translate this into a simpler form of English for me?
>>> I got lost.
>>
>>
>>
>> Sorry - I forget.
>>
>> Do you want a translation [1] in American English or Simple English?
>> I could run it though a translator [2] from real English to something
>> else and back again and in the process eliminate the subtilely [3].
>> Would that help? In the meantime here is the simple translation:
>
>
> another example of Stephen refusing to play nice.
:-)
> nothing has changed.
Yes - it's true .. Steve is a terribly nasty person.
But don't worry Berin, it's more raw material you can stow away.
Cheers, Steve,
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>> Can someone please translate this into a simpler form of English for me?
>> I got lost.
>
>
> Sorry - I forget.
>
> Do you want a translation [1] in American English or Simple English? I
> could run it though a translator [2] from real English to something else
> and back again and in the process eliminate the subtilely [3]. Would
> that help? In the meantime here is the simple translation:
another example of Stephen refusing to play nice. nothing has changed.
--
"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
Re: Avalon Versions
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Can someone please translate this into a simpler form of English for me?
> I got lost.
Sorry - I forget.
Do you want a translation [1] in American English or Simple English? I
could run it though a translator [2] from real English to something else
and back again and in the process eliminate the subtilely [3]. Would
that help? In the meantime here is the simple translation:
Your arguments don't make sense [4]
The world is changing [5]
Forget about the history [6] and focus on now.
Stephen.
[1] http://dictionary.reference.com/search?q=translation%20
[2] http://dictionary.reference.com/search?q=translator%20
[3] http://dictionary.reference.com/search?q=subtilely%20
[4] http://dictionary.reference.com/search?q=make%20sense
[5] http://dictionary.reference.com/search?q=changing
[6] http://dictionary.reference.com/search?q=history%20
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Berin Loritsch <bl...@d-haven.org>.
Can someone please translate this into a simpler form of English for me?
I got lost.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>> Stephen McConnell wrote:
>>
>>> Leo Sutic wrote:
>>>
>>>> Since there is no reasonable way of fixing the underspecification of
>>>> the 4.x versions without altering the framework, I think Niclas,
>>>> Stephen et al should switch to Avalon *5*, and just start cutting
>>>> cruft left, right and center.
>>>
>>>
>>>
>>>
>>> I think this is mixing politic with technical issues. Technically
>>> speaking if we were to doing something like removal of selectors -
>>> that would justify a major version bump because it represents a
>>> incompatible change. On the other hand the resolution of the
>>> underspecification issue can go a long way through minor version
>>> increments.
>>>
>>> Personally I prefer the approach of nailing down missing information
>>> on 4.X and getting out a 4.3 with a lot more semantic detail and
>>> deprecation of methods classes that we do not consider to be within
>>> 5.0. This approach ensures that a 4.X to 5.X migration is managed
>>> process based on a consistent with a well understood versioning
>>> doctrine. The alternative "leap" to 5.0 smells like a fork as
>>> opposed to a managed transition.
>>
>>
>>
>> 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.
>
>> 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.
>
>> 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.
>
>> 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).
>
> 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.
>
>> 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.
>
>> 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.
>
>> 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.
>
>> 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.
>
>> 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?
>
>> The core basics of Java2 version 5 and Servlet 2.x are
>> essentially the same, so there isn't as much of a need for a clean
>> break.
>
>
> As is the case with the avalon contract.
>
>> 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?
>
> ;-)
>
>> That's my two cents.
>
>
> 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.
>
> Cheers, Stephen.
>
>
--
"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
Re: Avalon Versions
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Leo Sutic wrote:
>>
>>> Since there is no reasonable way of fixing the underspecification of
>>> the 4.x versions without altering the framework, I think Niclas,
>>> Stephen et al should switch to Avalon *5*, and just start cutting
>>> cruft left, right and center.
>>
>>
>>
>> I think this is mixing politic with technical issues. Technically
>> speaking if we were to doing something like removal of selectors -
>> that would justify a major version bump because it represents a
>> incompatible change. On the other hand the resolution of the
>> underspecification issue can go a long way through minor version
>> increments.
>>
>> Personally I prefer the approach of nailing down missing information
>> on 4.X and getting out a 4.3 with a lot more semantic detail and
>> deprecation of methods classes that we do not consider to be within
>> 5.0. This approach ensures that a 4.X to 5.X migration is managed
>> process based on a consistent with a well understood versioning
>> doctrine. The alternative "leap" to 5.0 smells like a fork as opposed
>> to a managed transition.
>
>
> 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.
> 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.
> 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.
> 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).
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.
> 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.
> 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.
> 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.
> 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.
> 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?
> The core basics of Java2 version 5 and Servlet 2.x are
> essentially the same, so there isn't as much of a need for a clean
> break.
As is the case with the avalon contract.
> 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?
;-)
> That's my two cents.
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.
Cheers, Stephen.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Versions
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
> Leo Sutic wrote:
>
>> Since there is no reasonable way of fixing the underspecification of
>> the 4.x versions without altering the framework, I think Niclas,
>> Stephen et al should switch to Avalon *5*, and just start cutting
>> cruft left, right and center.
>
>
> I think this is mixing politic with technical issues. Technically
> speaking if we were to doing something like removal of selectors - that
> would justify a major version bump because it represents a incompatible
> change. On the other hand the resolution of the underspecification
> issue can go a long way through minor version increments.
>
> Personally I prefer the approach of nailing down missing information on
> 4.X and getting out a 4.3 with a lot more semantic detail and
> deprecation of methods classes that we do not consider to be within 5.0.
> This approach ensures that a 4.X to 5.X migration is managed process
> based on a consistent with a well understood versioning doctrine. The
> alternative "leap" to 5.0 smells like a fork as opposed to a managed
> transition.
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. It was its own project
and very jealously guarded for good reason. 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. This is the main point of
contention. The thing is that these things crept in not because of
evolution to the framework but because of evolution of the containers.
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.
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. 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.
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. The core basics of Java2 version 5 and Servlet 2.x are
essentially the same, so there isn't as much of a need for a clean
break.
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.
That's my two cents. I am offering what I consider a sane and decent
resolution to the process that will answer the concerns of all the folks
who are using Avalon _framework_ and move on. As of right now, I
consider all the other stuff to be Merlin container specific and it
seems as if the same care in preserving the framework is not being kept.
The version bump will help answer a lot of uneasyness. Oh and for an
example of version jumping, just check out Microsoft. When it went to
version 7 in the office suite, all the products had the same version
number, even if the last one was 2 or 3. I don't think that would be
too out of the question.
It is a non-technical answer to a non-technical problem.
--
"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
Re: Avalon Versions
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
> All,
>
> I've been following the latest threads, and just thought I'd jump in
> with two small comments.
>
> = 4.2 vs. 5 =
>
> Some have said that "of course 4.2 is incompatible with 4.1, you don't
> expect to use nio in a Java 1.3 environment, or a 2.3 servlet in a 2.2
> environment, do you?".
>
> Which is correct. If the minor version number increases, you can
> expect backwards compatibility for clients, but of course not for
> providers. But we're all in the business of developing providers.
>
> Which is why versioning in Avalon-land is perceived a bit different.
>
> A minor version change in framework is, for example, if you add a
> method to ExceptionUtils. The general opinion, as I remember it, is
> that a component-container contract change is a *major* version
> change. The fact that Serviceable/ServiceManager was a minor change
> should be written up as an exception.
I don't see why the addition of Serviceable/ServiceManager is any
different to the addition of a method to ExceptionUtils. In both cases
source and binary compatibility are maintained but consumers of the new
methods/classes are locking into a higher minor version.
> Above all, since contract changes impact container developers, they
> should be made in consensus with the most important container
> developers (Merlin team, Excalibur, Cocoon, etc.)
The decisions should be made with the concensus of the Avalon community.
> Since there is no reasonable way of fixing the underspecification of
> the 4.x versions without altering the framework, I think Niclas,
> Stephen et al should switch to Avalon *5*, and just start cutting
> cruft left, right and center.
I think this is mixing politic with technical issues. Technically
speaking if we were to doing something like removal of selectors - that
would justify a major version bump because it represents a incompatible
change. On the other hand the resolution of the underspecification
issue can go a long way through minor version increments.
Personally I prefer the approach of nailing down missing information on
4.X and getting out a 4.3 with a lot more semantic detail and
deprecation of methods classes that we do not consider to be within 5.0.
This approach ensures that a 4.X to 5.X migration is managed process
based on a consistent with a well understood versioning doctrine. The
alternative "leap" to 5.0 smells like a fork as opposed to a managed
transition.
Cheers, Steve.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org