Leo Simons wrote:
Stephen McConnell wrote:
Social stuff ------------
The social implications is:
* "it's not I the avalon namespace I don't have to worry about it"
you cannot battle negative social implications with code or specifications. That's plain dumb.
Another way of looking at it is that we can ignore the implications of our actions. Social implications play an important role in the development of systems, their usage, adoption, and value they deliver. To ignore that dimension is to ignore the damage that this vote is doing. Instead of dealing with the pain of reaching consensus - a vote is forced upon us. It is the cheap and easy option - the easy way out.
Here's the important social implication: the fact that you think it appropriate to state "I will ignore this group decision made by the accepted decision-making process we have put in place as a group because I may disagree with the result" over something as silly as a naming convention, dragging us all back into long e-mails full of debate about bike sheds has hereby led to the end of my involvement in talks about and work on implementing a common avalon metadata system. This is not how I want to develop stuff.
There are a couple of misconceptions you have.
Firstly you categorization of this issues as "something as silly as a naming convention" is completely missing the point. Its not about "do we name it this or do we name it that" - its about the thing we name and having at least some degree of integrity about that thing. I.e. assume for a moment that this is all about packaging something under the namespace of "component". E.g. @component.depedency, @component.entry, @component.stage. The model named by a namespace. The namespace presents a specific solution space. To propose @component under the guise of something to foster reliable component deployment would be out and out misleading because it is technically incomplete. If we refocus this scenario by substituting @component with @avalon, we compound the error.
Have fun writing it on your own.
Happily, I'm not on my own.
Contractual stuff -----------------
This is complicated by a contractual limitations:
* "the avalon namespace model does not support model extension"
avalon does not need a formal namespace model with extension capability. Look at how much trouble the XDoclet people have managing their dozens of tags (namely: none). We're certainly not likely to have more than them.
Leo - again your missing the point. The objective is a framework whereby we can declare meta data once (irrespective of the containment environment) and from that achieve reliable component deployment. Nobody has presented anything of substance to discount the objections I raised concerning the implications of Berin's vote. Give me a solution that maintains integrity of the objective! Don't give me arguments that have nothing to do with the subject we are discussing.
Sigh.
You know how much work it is to replace @lifecycle with @avalon.lifecycle? It goes a little something like
s/@lifecycle/@avalon\.lifecycle/
in perl. Which is something just about every reasonable editor on this planet can do with a few keystrokes or a few mouseclicks. In fact, I can do that ASF-wide to all sourcecode in less time than it takes you to reply to this e-mail.
I'm assuming this said with a somewhat tongue-in-cheek posture. Just in case anyone were to take this comment seriously, I should put out that this has nothing to do with substitution of text strings. It has everything to do with responsibility.
Some pointless bickering
------------------------
My turn to sigh?
:-)
just for fun, I'll point out some things that are plain wrong:
OK. Lets find out how stupid I really am.
if something is not inside Avalon namespace - well - it just does not exist in terms of something standard and recognized.
wrong. java.lang for example is standard and recognized. So is log4j. Standards don't need a namespace.
Your misunderstanding my comment. Perhaps I did not write it clearly so I'll have a go a re-stating this more clearly. Firstly, I am discussing these things with an Avalon context - I am not discussing global concerns, java concerns, or Apache concerns. I think it is reasonable that anyone reading my comments on this subject would have equated my concerns with what "Avalon" establishes as a standard. Clearly you appear to have been confused on this point and as such, I can only offer my apologies together with a promise to be a touch more verbose in the future.
The @avalon.stage tag does not dictate a mechanisms to a container
the way you're putting it it does: you are stating that all containers must have a mechanism in place to parse some kind of data about lifecycle extensions and then kick out a component.
Let me clarify. In order for Avalon to provide a common and consistent model for the declaration of container responsibilities towards a container we have developed a set of tags. These tags can be used to generate an information model - common referred to as a meta-info model . Today we have three containers. Each container employs a different meta-info model. In your absence a lot of work has gone into putting in place a complete a meta-info model and a set of supporting tags that will ensure a migration path from the current approach towards a unified approach. The unified approach is what will enable any container to verify, prior to deployment, if a component is supportable or not.
There is a proposal (and unfortunately a vote) that if successful will fragment this community and initiate divergence. One must ask why are we not uniting and embracing everyone's needs (i.e. Phoenix, Fortress and Merlin). One must question why a solution proposed that does not even meet the objective.
If we retract the @avalon.stage (and the corresponding @avalon.extension) tags from the Avalon namespace, we are stating that the notions of deployment phase (versus classic runtime phase) notions are concepts that can be ignored.
wrong. We are seperating concerns.
I agree that *we* are separate concerns, however, I was not referring to you or I. I was in fact referring to the semi-royal we a.k.a. Avalon Community. If by chance you were not referring to you and I, then I would suggest that your taking a very technical view and in doing so, you risk ignoring the big picture and missing the basic objective of the @avalon process.
If you remove @avalon.stage from core Avalon - then any component that leverages deployment phase dependencies (i.e. components that fulfill stage execution) will no longer be a valid Avalon components.
wrong. "valid avalon component" is defined by providing a no argument constructor, a work interface and following IoC. That won't change.
Should I assume that Avalon is already dead and buried? Avalon was (at least in my simplistic view of the world) an evolving environment - if I remember correctly, Marcus Crafter announced the availability of lifecycle extensions under Fortress back in September last year. Not long afterwards the same concept (based on the original work from Marcus) was introduced to the Merlin platform. It took something like nine months to release a package with less than half-a-dozen classes, but that release signaled the establishment of a formal Avalon abstraction. The notion that a component can be deployed with a variable set of lifecycle stages. That abstraction (as you are well aware) has provided highly valuable in a number of areas and application scenarios. It is that same abstraction that that introduced that the notion of a stage as a computational dependency exposed by a component towards a container.
While I'm not into lecturing on history - I do think that we should recognize the past and be responsible for what we have released and the semantics they imply.
The implication of this is that a container could be asked to deploy such a component, and unless the component does its own error checking to validate that in fact its lifecycle stages have been executed, we enter the gray zone of unpredictable components. This gray zone is components executing on the assumption that they have been fully deployed. This potential false assumption can lead to failures in security, inconsistency in service delivery behavior, and potential damage by a component simply because it is acting under incorrect assumptions.
indeed. Someone who deploys an application into a container and uses advanced features better check they're supported. Just like you should deploy a component that uses javax.logging on jdk 1.3.
We are not talking about advanced feature - we are talking about released features. As to your point "[they] better check they're supported" - that something central to this entire discussion. If your deploying a component using JNLP (as an example), and you don't have a developer babysitting the process - what happens with the scenario that Berin is proposing is that the solution (a) runs because your lucky, (b) fails with a stack trace because sort of lucky, (c) does something it was not intended to do because we (Avalon) decided to ignore the contracts that we (Avalon) established and released.
Do you feel comfortable endorcing this position?
Containers outside (and quite probably inside) Avalon will ignore @lifecycle because its not part of a "core" @avalon contract.
containers inside and outside avalon ignore some parts of avalon-framework that have been in place since version 4.0. I would argue that ComponentSelector is at the very core of the core of avalon.
We are not defining an interface - we are defining the information that a component communicates to a container concerning constraints it imposes on its deployment and runtime life. These are very different subjects.
One cannot simply retract this tag from the Avalon namespace without providing a solution.
wrong. No application I have ever written will suffer. No application deployed on released avalon code will suffer. No application to deployed on to-be-released avalon code will suffer more than a search-and-replace incovenience.
I would categorize your conclusion as a naive generalization. Avalon will suffer significantly because we will have failed miserably at delivering what we have been promising. We will have failed to back up what we have released and we will be promoting an incomplete model of what we are about. Avalon looses credibility. Avalon utility is decreased. All of that is put at stake because one individual wants to force a vote on a half-baked solution.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
