Return-Path: 
 <dev-return-25170-apmail-avalon-dev-archive=avalon.apache.org@avalon.apache.org>
Delivered-To: apmail-avalon-dev-archive@avalon.apache.org
Received: (qmail 30050 invoked by uid 500); 28 Jul 2003 10:19:27 -0000
Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@avalon.apache.org>
List-Subscribe: <mailto:dev-subscribe@avalon.apache.org>
List-Help: <mailto:dev-help@avalon.apache.org>
List-Post: <mailto:dev@avalon.apache.org>
List-Id: "Avalon Developers List" <dev.avalon.apache.org>
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Delivered-To: mailing list dev@avalon.apache.org
Received: (qmail 30035 invoked from network); 28 Jul 2003 10:19:26 -0000
Received: from main.gmane.org (80.91.224.249)
  by daedalus.apache.org with SMTP; 28 Jul 2003 10:19:26 -0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19h56M-0005Dc-00
	for <dev@avalon.apache.org>; Mon, 28 Jul 2003 12:19:34 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: dev@avalon.apache.org
Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 19h56L-0005D0-00
	for <gmane-comp-jakarta-avalon-devel@m.gmane.org>;
 Mon, 28 Jul 2003 12:19:33 +0200
From: Leo Simons <leosimons@apache.org>
Subject: Re: [Proposal] AMTAGS
Date: Mon, 28 Jul 2003 12:19:36 +0200
Lines: 96
Message-ID: <bg2tbk$jhp$1@main.gmane.org>
References: <3F222C92.30903@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@main.gmane.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
In-Reply-To: <3F222C92.30903@apache.org>
Sender: news <news@main.gmane.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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