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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
