Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 21999 invoked by uid 500); 7 Mar 2003 11:35:29 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 21986 invoked from network); 7 Mar 2003 11:35:28 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 7 Mar 2003 11:35:28 -0000 Received: (qmail 29876 invoked from network); 7 Mar 2003 11:35:27 -0000 Received: from unknown (HELO apache.org) (stefano@80.105.91.155) by pulse.betaversion.org with SMTP; 7 Mar 2003 11:35:27 -0000 Message-ID: <3E688400.9060102@apache.org> Date: Fri, 07 Mar 2003 12:35:28 +0100 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: cvs commit: xml-cocoon2 build.xml References: <20030304163435.10242.qmail@icarus.apache.org> <1046829775.26174.24875.camel@ighp> In-Reply-To: <1046829775.26174.24875.camel@ighp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N David Crossley wrote: > cziegeler@apache.org wrote: > >>cziegeler 2003/03/04 08:34:35 >> >> Modified: . build.xml >> Log: >> Making cocoon at least buildable; > > > Thanks. Actually, validation did work when i committed it. > Erk, i see what the problem was - i forgot to commit > the "any.rng" grammar ... sloppy, sorry. > > >>why are there two validations and why in the init? > > > They are done once high up in the build to catch errors > with the default config files. Then they are done again > after the bits from the blocks have been merged. I thought > that my comments in the build.xml said that (i will clarify). > > Why in the "init"? ... because it should fail straight away > if there are problems with the main config. Should that be > moved to another early build target? configuration validation should happen right before the configuration is required. This means, that 'webapp' should depend on 'validate-config'.