You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by David Crossley <cr...@indexgeo.com.au> on 2003/03/05 03:02:51 UTC
Re: cvs commit: xml-cocoon2 build.xml
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?
> Revision Changes Path
> 1.350 +5 -5 xml-cocoon2/build.xml
<snip, Carsten commented-out cocoon.xconf validation/>
--David
Re: cvs commit: xml-cocoon2 build.xml
Posted by Stefano Mazzocchi <st...@apache.org>.
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'.
RE: cvs commit: xml-cocoon2 build.xml
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David Crossley wrote:
>
> Carsten Ziegeler wrote:
> > David Crossley wrote:
> <snip/>
> > >
> > > 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?
> > >
> > The problem with "init" is, that it is executed for any target,
> > so even if you make a "build clean", init is executed and this
> > then tries to validate. Yesterday I wasn't even able to make
> > a "build clean" because of "validation errors". So, I think
> > this is the wrong place.
>
> Thanks, i did not know that. So then targets do not explicitly
> need a ... depends="init", like we have now.
>
They need - sorry, it was a rather short description from me. The
"init" is executed for any target, because we have the depends="init"
clause for each target as some basic settings like paths and
properties are set there.
> I have moved that stuff out of "init" and into "prepare".
Great! Thanks, David!
Carsten
RE: cvs commit: xml-cocoon2 build.xml
Posted by David Crossley <cr...@indexgeo.com.au>.
Carsten Ziegeler wrote:
> David Crossley wrote:
<snip/>
> >
> > 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?
> >
> The problem with "init" is, that it is executed for any target,
> so even if you make a "build clean", init is executed and this
> then tries to validate. Yesterday I wasn't even able to make
> a "build clean" because of "validation errors". So, I think
> this is the wrong place.
Thanks, i did not know that. So then targets do not explicitly
need a ... depends="init", like we have now.
I have moved that stuff out of "init" and into "prepare".
Great, thanks Carsten.
--David
RE: cvs commit: xml-cocoon2 build.xml
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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.
>
No problem.
> > 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?
>
The problem with "init" is, that it is executed for any target,
so even if you make a "build clean", init is executed and this
then tries to validate. Yesterday I wasn't even able to make
a "build clean" because of "validation errors". So, I think
this is the wrong place.
Carsten