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.
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.
Have fun writing it on your 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.
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.
Some pointless bickering ------------------------ just for fun, I'll point out some things that are plain wrong:
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.
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.
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.
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.
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.
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.
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.
* moving out of core means death to the idea of reliable deployment across containers
FUD.
* an absence of an extension mechanism in @avalon core makes the proposal technically invalid
wrong.
Now is not the time for another divergent split in Avalon
very right. Maybe you should dim your tone in order to avoid such divergence.
containers that recognize the full criteria and containers that claim Avalon compliance but ignore the reality of what developers are doing using release Avalon product).
FUD.
g'night!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
