avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [Proposal] AMTAGS
Date Mon, 28 Jul 2003 10:19:36 GMT
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


Mime
View raw message