J Aaron Farr wrote:
On Mon, 2003-07-21 at 16:00, Berin Loritsch wrote:
The ones that are close to the current AMTAGS proposal are:
@avalon.component, @avalon.service, and @avalon.dependency
So what are the issues of adopting these three tags as defined by the meta package into AMTAGS?
Now, for the lifecycle extensions tags (i.e. @avalon.extension, @avalon.stage)
I propose that we move them to a functional namespace: @lifecycle.extension and
@lifecycle.stage). I still get confused over which references what, so I need
a little information on that. Does ".extension" reference the interface that
is the lifecycle extension? If so, that would mean that ".stage" would
reference the Creator/Accessor that does the actual logic for extending the
component's lifecycle.
Stage = service which uses a lifecycle extension
Extension = service which can provide support for a lifecycle extension
Using the word "service" is a little dangerouse in this context because there isn't a service to speak of. A stage is the component side of the contract and an extension is the container side of the contract. A stage is executed by an extension - and extension executes a stage. A container makes the decision of which extension implementation to apply to a declared lifecycle stage.
I get them mixed up too.
Merlin also has support for what are currently dubbed "DeploymentStageExtensions" which are similar to Lifecycle Creator Extensions, only these extensions have access to the Appliance.
I suggest we leave these exetended extensions out of the picture for the moment - reason is that I'm working on seperating model information from assembly information so that an extension of this type will not have access to a navigatable structure. In the meantime, Merlin will recognize the type of extension based on the interfaces it implements (not great for interoperability but at least we have the ability to play around with this some more).
Also, Stephen recently added support for extension handlers to be
identified by strings (think urn's) instead of class names. These two
modifications open up a number of possibilities and I'd like to see
support for it eventually make it's way into Fortress and Phoenix.
Me too.
Lastly we have a generic @avalon.attribute tag that is nice and flexible.
However, it is unclear to me from the code where it is recognized. It appears
to only be recognizable from the main class JavaDocs from the ANT tag code.
According to the model code, attributes would be applicable to the type, the
service, and dependencies. It is unclear to me how we scope the attributes
to the specified dependency or service (if the service is specified with the
component implementation).
Yes. I had trouble with this as well. For example, the following should be valid in a merlin .xinfo file:
<stages>
<stage type="org.apache.avalon.plyground.Demonstratable:1.0.0">
<attributes>
<attribute name="description" value="an example"/>
<attribute name="color" value="red"/>
<attribute name="priority" value="normal"/>
</attributes>
</stage> </stages>
But I have no idea how to specify this in doclet tags. In fact, I'm not sure if the current code supports it.
Current code does not support it - if you want to leverage attributes at anything other than component level you need to hand-craft you xinfo descriptor.
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]
