Return-Path: 
 <dev-return-71227-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 63056 invoked from network); 12 Feb 2005 20:18:01 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 12 Feb 2005 20:18:01 -0000
Received: (qmail 35327 invoked by uid 500); 12 Feb 2005 20:17:59 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 35293 invoked by uid 500); 12 Feb 2005 20:17:59 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 35279 invoked by uid 99); 12 Feb 2005 20:17:59 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from Unknown (HELO blossom.betaversion.org) (62.140.213.100)
  by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 12 Feb 2005 12:17:57 -0800
Received: by blossom.betaversion.org (Postfix, from userid 101)
	id 90DC5973F4; Sat, 12 Feb 2005 20:12:27 +0000 (GMT)
X-AntiVirus-Version: ClamAV 0.81/705
X-AntiSpam-Version: SpamAssassin 3.0.2
X-AntiSpam-Status: No (score=1.7/limit=7.5)
X-AntiSpam-Rules: rcvd_in_njabl_dul, listed
Received: from [192.168.1.100] (h-68-166-233-100.cmbrmaor.dynamic.covad.net
 [68.166.233.100])
	by blossom.betaversion.org (Postfix) with ESMTP id C7F47973ED
	for <dev@cocoon.apache.org>; Sat, 12 Feb 2005 20:12:26 +0000 (GMT)
Message-ID: <420E6474.5000304@apache.org>
Date: Sat, 12 Feb 2005 15:17:56 -0500
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [2.2] Dynamic xconf try to open non-existing files (bug?)
References: <34395.10.0.0.5.1108216159.squirrel@www.agssa.net>
 <420E3260.9040007@apache.org> <420E3E82.3050409@apache.org>
 <420E522B.6060207@apache.org>
In-Reply-To: <420E522B.6060207@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> 
>> Stefano Mazzocchi wrote:
>>
>>>
>>> The more it think about this, the more I believe that <imports> 
>>> should not be done explicitly but implicitly, based on some 
>>> aggregated dependency information (for example, the blocks should 
>>> have their block descriptor block.xml and include the dependency 
>>> information there)
>>>
>> I think this is not too hard to do: a simple ant task that copies the 
>> xconf for a block into the xconf directory and adds all include 
>> statements.
>>
>> If I have time, I will look into that this weekend, but can't promise 
>> anything :)
> 
> The include features in xconf allows to very simply add or remove a 
> block by just moving files around. I would like to keep this simplicity 
> and avoid by all means to go back to some build-time generation of these 
> files like we have today with xpatch in 2.1

Amen.

> There aren't that much inter-block dependencies, and I don't have the 
> feeling hand maintaining them is really complicated.

What I would like to see is something like this:

1) src/block/*/block.xml

that contains something as simple as

  <block name="a">
   <depends-on block="b"/>
   <depends-on block="c"/>
  </block>

2) this info used by cocoon at startup time (NOT COMPILE TIME!) to drive 
the xconf imports.

How hard can that be!?!

-- 
Stefano.