Berin Loritsch wrote:
The more I think about it, the less I like Stage and Extension being in the
Avalon namespace. I just have this nagging feeling that these tags will be
superceded in the future by something else. Consider all the evangelization
that Peter D. did with interceptors. I have dabbled with interceptors, and
they do open up a wide variety of different possibilities. That said, I am
not ready to dump some code out there and have it start being used.
Since the Avalon namespace should reflect stability, and the abilities that
the tags represent are not core to pure Avalon components, I really am
having a hard time justifying their existence in the Avalon namespace.
The notion of a lifecycle stage is core to Avalon at this level of abstraction. We are talking about a dependency that a component has during its deployment cycle. We are not talking about how the dependency is resolved or applied.
In the short term, they will work just fine.
I think you mixing up concerns about excalibur-lifecycle with the separate aspect of the lifecycle stage dependency declaration. These are two different things.
However we have to consider the long term.
We certainly do. In the longer terms I expect the concept of a lifecycle stage to remain as an intrinsic element of our component model. I also anticipate that we will evolve different solution strategies to deal with these deployment dependencies. One fundamental truth is that lifecycle stage dependencies will not disappear - what will change is how those dependencies will be handled.
Certainly new things will come along that we will want to experiment with, and after that experimentation we may want to consider other approaches - approaches that leverage the stage and extension tags.
For that reason, I strongly recommend that we put these two tags in their
own namespace.
I strongly disagree with you recommendation. The notion of a stage is intrinsic to the component model.
For the short term, we [could] modify all the containers to
at least recognize the tags
1. Tools recognize tags - containers recognize meta-info.
2. what you describing is actually container recognition of a particular dependency - in this case a stage dependency which is core to validation of a type
and decide whether they can support the lifecycle extensions or not.
I mentioned in one of my earlier emails that we need to clarify our specification approach. I don't think that the @avalon tags should be specified in terms of container constraint or obligations. In effect the AMTAGS spec should be targeted to the tool builder. Tools, such as a meta-info generator can create meta-info - its the meta-info specification that carries implications relative to a container.
The impact to Merlin is a tag name change, which is inconvenient but not
such a high impact as to be a blocker.
Consider it a blocker - because I think (a) your looking at this from an implementation point of view and (b), I think your looking at this from the wrong abstraction level (but I'm not sure) and (c), acceptance of your position would inconsitent with the meta-info model and would be detrimental to overall meta-model work in which these notions are intrinsic first class aspects.
As none of the other containers
support the tags in the manner that Merlin does there is no impact on them.
What your really saying is that Merlin is the only container platform that provides support for explicitly declared stage dependencies. Without this notion, components using stages in Fortress will fail in an unpradictable manner in both Phoenix and Merlin. Lets get back to the purpose of AMTAGS. It about declaring criteria such that (a) we use tags in a consitent manner enabling and forstering tool development, and (b) enabling and facilitating and common meta-info model through which we will able to achieve component portability across containers.
After saying all that, I would like Fortress and Merlin to be on the same
page for declaring and using the extensions (making them more cross-container
compatible). The change would be made to Fortress--not Merlin.
Presumably Fortess will migrate to the meta-info model. Multiple examples exist in the avalon-sandbox/merlin repo - let me known if you need a hand.
I propose that the tags currently named @avalon.stage and @avalon.extention
be placed in the "lifecycle" namespace making their names be @lifecycle.stage
and @lifecycle.extention.
-1
The stage and extension tags reflect an abstract semantic that flows down through the complete meta-info model. I cannot agree to your proposal because of the "thin-edge-of-wedge" factor. Lifecycle stages are intrinsic elements of a Type definition. A type definition is mirrored by component meta-data. Component meta-data is managed as a component meta-model. A meta-model is reflected in a deployment system. Your recommendation would initiate a fragmentation of what is a complete, consistent and functional structure.
By placing them in another namespace, we can keep the tags and the abilities
they represent without having to try and argue them in. I tried to like them
in the Avalon namespace, but the more I tried the more uneasy it made me.
I am certainly happy to help you out with anything concerning the handling of extension and stage mapping. In fact, if you careful about the approach to internal management you can abstract yourself from the lifecycle extension API. This shifts the focus of stage and extension to be concerns related to deployment and (as distinct from runtime) dependency management.
My guess is that this is probably where you and I are disagreeing. I view stage declarations as something more abstract than the lifecycle extension package - and something totally intrinsic to open component management. What is fundamentally important is the Avalon component model has a distinction between runtime and deployment dependencies. The solution to meeting those dependencies remain a container concern.
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]
