You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/07/26 09:24:02 UTC
[Proposal] AMTAGS
Proposed AMTAGS Specification
-----------------------------
A complete specification of the proposed AMTAGS tags is included under
the following link:
http://avalon.apache.org/sandbox/avalon-meta/tools/tags/index.html
The link provides an overview of the 10 tags required to complete cover
all features of a component across all containers. The specification
places absolutely no obligation on a developer to use these tags.
Instead, the tags present a consistent approach to component type
adornment that can be used by tool authors and container authors in
validation, deployment and/or runtime.
The compete spec covers the following tags:
@avalon.component
@avalon.attribute
@avalon.service
@avalon.stage
@avalon.extensions
@avalon.logger
@avalon.context
@avalon.entry
@avalon.dependency
For every tag the spec contains:
* description of the tag
* the full list of tag attributes
* example tag usage
* corresponding tool output
The proposal has been validated through an Ant task and a Maven plugin.
Using Maven plugin you can use the above tags without incurring and
project level dependency - simply invoke "mavenavalon:meta" after
installing the plugin.
Remaining Issues
----------------
The proposal isn't totally finalized yet:
Attribute management - we need to deal with a general attribute
management approach because attributes apply to things like services,
dependencies, context, etc.
Removal of container constraints - currently the wording of the spec
contains phrases that imply constrains on a container. These should be
removed as this is a concern of a meta model (possibly created via a
tool). Instead – purpose and compliance documentation must be updated to
describe tool compliance criteria.
In the meantime please take an opportunity to tack a look - all feedback
appreciated.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] AMTAGS
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Proposal? What proposal? Why is everything always called proposal?
> ------------------------------------------------------------------
I could give you a really synical answer to that but I won't! In
practice I think flagging something as a proposal does hint at a
precursor to a decision.
>
> ok. Read it, digested most e-mails on the subject. Didn't feel like
> thoroughly reading everything. You guys produced approximately 100 A4
> pages of mails on this I think.
>
> Seems like avalon-meta is ready for a first release and containers can
> be updated to use it. I think there's something in place that works.
> For me it is way overkill but its not in the way either.
>
> So, what is the actual proposal?
>
> Rename avalon-meta to AMTAGS? Why? Better to just loose the AMTAGS
> name if you ask me. Avalon-meta is clearer.
>
> Migrate avalon-meta from the sandbox? Do a few alpha releases first, imo.
+1
IMHO this is the only strategy that makes sence.
>
>
> Add support for tags, by using avalon-meta, to all containers? Sure.
> Enthusiastic +0.
>
>
> On Part2 and Part3 vs just one Part
> -----------------------------------
> No, I need none of
>
> @avalon.stage
> @avalon.extensions
> @avalon.logger
> @avalon.context
> @avalon.entry
>
> but I don't see a problem with them either. Go ahead and just do all
> of that. We can always change it later.
>
> I do like configuration validation. It'd be real nice to have fortress
> do it :D
>
>
> Some actual comments on tags
> ----------------------------
>
>> @avalon.component
>
>
> The whole versioning scheme should be explained. I think Steve
> previously answered most of the questions I posed but that didn't make
> it into the docs yet apparently.
I can take care of that either before or after a release. Personally I
would prefer to do it after with a little more time to document it
properly, but I can do it now if its view as a critical thing. Just for
reference, while you were away I updated the Version class in framework
to support the notion of an undefined version (represented as -1). By
default the versions associated with any dependency (service runtime
dependencies and stage dependencies) defaults to -1 (i.e. any version,
i.e. ignore version). This simply means that not declaring versions will
not interfere with anything.
>
>
>> @avalon.attribute
>
>
> I still think it is silly to have an attribute named attribute. Mad.
Lets deal with this post 1.0. The attribute management still needs to be
done and with that in place the need for @avalon.attribute disappears.
>
>> @avalon.service
>
>
> comment on versioning above applies.
Noted.
>
>> @avalon.stage
>> @avalon.extensions
>
>
> so no @lifecycle then?
We have a choice of either:
(a) completely addressing the entities at the current level of abstraction
(b) changing the abstraction of the entire model
Or to put it more simply - the current level of abstraction deals with
the expression of constraints that a component implies towards a
container. If the constraint set is incomplete the solution is
dysfunctional. If we consider lifecycle outside of the current
abstraction then we have to rebuild the Avalon abstraction to encompass
custom abstraction inclusion. This is a non-trivial problem that should
be investigated and experimented with based on real requirements.
>
>> @avalon.logger
>
>
> there's an @avalon.configuration up next that is new (to me), and you
> didn't list it either.
Sorry about that - but it is listed here:
http://avalon.apache.org/sandbox/avalon-meta/tools/tags/index.html
> I guess this can be a relaxng reference and is similar to phoenix
> config validation:
That's the objective.
>
>
> Peter Royal wrote a long time ago (thanks google):
> > Phoenix will look for a schema-type element in the blockinfo document,
> > and if it is found, will attempt to load <block>-schema.xml as the
> > schema. If you are using the xdoclet xinfo generation, add
> > @phoenix:configuration-schema type="<type>" in the javadocs of the
> > configure() method.)
>
> is this avalon-meta thing just for relaxng schemas as well? Is there a
> need to support different schemas? Is there actual code to support this?
There is code in the Phoenix repository that handles this. I was
thinking about what we could do at a tool level to validate
configurations ahead of deployment (and I'm still thinking - no solid
opinion yet).
>
>
>> @avalon.context
>
>
> as long as we're clear on the notion that actually extending the
> context interface is bad practice :D
Calling it a bad practice feels a little over the top to me. In
proactive it’s a balance - on one hand the component developer is
restricting their deployment options (because not all containers provide
implementation support), on the other hand, users like using domain
based context objects. The decision that a developer makes in this
regard is neither good nor bad. It’s simply a decision. But I know what
your saying - sort of agree - but wanted to state the concern more
completely.
>
>> @avalon.entry
>> @avalon.dependency
>
>
>
> > Remaining Issues
> > ----------------
>
> leave those for v1.1 if you ask me :D
I agree.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Proposal] AMTAGS
Posted by Leo Simons <le...@apache.org>.
Proposal? What proposal? Why is everything always called proposal?
------------------------------------------------------------------
ok. Read it, digested most e-mails on the subject. Didn't feel like
thoroughly reading everything. You guys produced approximately 100 A4
pages of mails on this I think.
Seems like avalon-meta is ready for a first release and containers can
be updated to use it. I think there's something in place that works. For
me it is way overkill but its not in the way either.
So, what is the actual proposal?
Rename avalon-meta to AMTAGS? Why? Better to just loose the AMTAGS name
if you ask me. Avalon-meta is clearer.
Migrate avalon-meta from the sandbox? Do a few alpha releases first, imo.
Add support for tags, by using avalon-meta, to all containers? Sure.
Enthusiastic +0.
On Part2 and Part3 vs just one Part
-----------------------------------
No, I need none of
@avalon.stage
@avalon.extensions
@avalon.logger
@avalon.context
@avalon.entry
but I don't see a problem with them either. Go ahead and just do all of
that. We can always change it later.
I do like configuration validation. It'd be real nice to have fortress
do it :D
Some actual comments on tags
----------------------------
> @avalon.component
The whole versioning scheme should be explained. I think Steve
previously answered most of the questions I posed but that didn't make
it into the docs yet apparently.
> @avalon.attribute
I still think it is silly to have an attribute named attribute. Mad.
> @avalon.service
comment on versioning above applies.
> @avalon.stage
> @avalon.extensions
so no @lifecycle then?
> @avalon.logger
there's an
@avalon.configuration
up next that is new (to me), and you didn't list it either. I guess this
can be a relaxng reference and is similar to phoenix config validation:
Peter Royal wrote a long time ago (thanks google):
> Phoenix will look for a schema-type element in the blockinfo document,
> and if it is found, will attempt to load <block>-schema.xml as the
> schema. If you are using the xdoclet xinfo generation, add
> @phoenix:configuration-schema type="<type>" in the javadocs of the
> configure() method.)
is this avalon-meta thing just for relaxng schemas as well? Is there a
need to support different schemas? Is there actual code to support this?
> @avalon.context
as long as we're clear on the notion that actually extending the context
interface is bad practice :D
> @avalon.entry
> @avalon.dependency
> Remaining Issues
> ----------------
leave those for v1.1 if you ask me :D
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org