Sorry,
I had meant to reply earier.
The reason it is the way it is, is for backward compatibilty.
Initially, there was no attribute in the <typedef> task to
specify what would happen if there was a failure. I wanted to use
the typedef task in the antlib specification, and so I needed an attribute
to allow optional tasks/types to be specified, so the onerror attribute
was written for this.
The default setting of the attribute was to specify the behaviour of
<typedef>
in ant 1.5.4 and earier - I called this "FAIL", but in ant 1.5.4, if one
specified a
resource or a file that did not exist, it will be reported but will not fail
the build.
The build would only fail if the build tried to make use of the type or
task, in
which case it would fail.
As example of a build script not failing for a missing resource but
reporting
a warning is the check.xml build file that is in the ant cvs.
However because now there is an attribute that explicity says that one
should
fail, and it does not, this is clearly wrong.
I see two solutions:
1) change the meaning of onerror="warn" so that it reflects the current
onerror="fail"
behaviour. and make this the default and modify onerror="fail" to
fail if the resource
or file cannot be read.
2) make a new onerror="warn_and_report" state to reflect the current
behaviour and modify
onerror="fail" as above.
Peter
steve morin wrote:
>could some one take a look at Bugzilla Bug 31685 [PATCH] typedef
>doen't fail with resource could not be found.
>
>I supplied a patch fix and patch for unit tests and results.
>Steve
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
|