------------------------------------------------------------------
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
