Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 71558 invoked from network); 11 Nov 2003 09:30:07 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 11 Nov 2003 09:30:07 -0000 Received: (qmail 88772 invoked by uid 500); 11 Nov 2003 09:29:39 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 88733 invoked by uid 500); 11 Nov 2003 09:29:39 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 88719 invoked from network); 11 Nov 2003 09:29:39 -0000 Received: from unknown (HELO sati.virbus.de) (145.253.246.81) by daedalus.apache.org with SMTP; 11 Nov 2003 09:29:39 -0000 Received: from sati.virbus.de (localhost [127.0.0.1]) by localhost (SMTP Server) with ESMTP id A5BEA166AAE for ; Tue, 11 Nov 2003 10:29:51 +0100 (MET) Received: from virbus.de (a183069.studnetz.uni-leipzig.de [139.18.183.69]) by sati.virbus.de (SMTP Server) with ESMTP id 4E051166A49 for ; Tue, 11 Nov 2003 10:29:51 +0100 (MET) Message-ID: <3FB0AC41.7080104@virbus.de> Date: Tue, 11 Nov 2003 10:30:41 +0100 From: Joerg Heinicke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-de, de, en-us, en-gb, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: auto generation of blocks.properties References: <9DB75C1A-141C-11D8-9AAD-000393CFE402@apache.org> In-Reply-To: <9DB75C1A-141C-11D8-9AAD-000393CFE402@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On 11.11.2003 08:56, Bertrand Delacretaz wrote: > Le Mardi, 11 nov 2003, � 00:20 Europe/Zurich, Joerg Heinicke a �crit : > >> ...Another solution IMO are the complete dependencies in our >> blocks.properties. But maintaining both gump.xml and blocks.properties >> is a pain. The solution is to have one file and to generate the other >> one.... > > > +1, actually this info should come from the blocks directly (metadata), > but this is for later... This stylesheet was especially for the time we don't have the "real" blocks. But of course maybe we can have some intermediate, i.e. a time where we have the blocks, but not the block deployer. There another stylesheet can also help. > I like the idea of generating blocks.properties from gump.xml. > > I'd just add a prominent notice at the beginning of the generated > blocks.properties: "autogenerated - do not edit" or something. This depends. If it is only a helper target it will be called on demand. It would be the same as a committer is editing the blocks.properties and commits it. Now he needs not to edit it by hand but generate it automatically. It's another issue if it is deeper integrated into the build process. Remove blocks.properties from CVS, starting the generation on the first build, later on it will be updated after an update on gump.xml, the user get's again it local.blocks.properties and *must* change the blocks deployment there. But how to keep it in sync? Adding a warning on the screen if the blocks.properties is newer than local.blocks.properties? It's not easy as you can see. It's also only a temporary solution. Joerg