Actually, when the "failonerror" parameter is set to true, the build process is stopped when the parser finds an error in a file. The problem appears when we have several files to validate and that we don't want to stop the validation process on the first error. We should be able to choose to validate or not all the files, log the errors and then stop the build process if we have encountered any errors. A "haltonerror" parameter could be used to achieve this goal. If set to true, we stop the build process when we encounter an invalid file. If set to false, we validate ALL the files and stop the build process only if we have encountered some validation errors.
better to have a failureproperty that is set on success... no, better to make xmlvalidate a condition that can be used in a <condition> or <fail> statemement. In the meantime, 1. why not break things up into multiple files? I do that, after using <presetdef> to set up XSD validation right. 2. There is actually a sort-of-bug with multifile validation in xmlvalidate in ant1.6; we dont reset the parser. Current versions of xerces require a new parser for every validation. So only ant1.7 will do bulk files properly, all the time.
I know about the multifile validation problem in xmlvalidate (ant1.6). I'm using the last version in CVS, so I don't have this bug. I'm just disappointed not to be able to choose to validate all the files against my XSD and log errors before choosing to make the build process fail with the "failonerror" parameter. I'm not sure I've well explained what I want to achieve : I've got 10 files, 3 of these files are invalid according to my XSD. If I use xmlvalidate, the build process will stop when the parser will meet an invalid file (Only if "failonerror" set to true. If set to false, the build process will never be stopped). As a consequence, not all the files will be validated. It will be more interesting if the 10 files can be validated, log all the errors for the 3 incorrect ones and stop the build process if the parser reports some errors. If I understand well, you think it will be a better idea to use a failureproperty that will be set on success if the "failonoerror" parameter is set to false (in order to validate every file without stopping the build process). Is it correct ? This idea sounds great also. I beg your pardon but I don't understand what you've said about breaking things up into multiple files. How can it help ?
multiple files. This is what I mean. But that doesnt do what you want either, does it? <target name="test-documents" description="validate the CD: test documents" depends="init"> <validate-cddlm file="${valid.dir}/minimal.cdl"/> <validate-cddlm file="${valid.dir}/extra-elements.cdl"/> <validate-cddlm file="${valid.dir}/webserver.cdl"/> <validate-cddlm file="${valid.dir}/webserver-no-namespace.cdl"/> <validate-cddlm file="${valid.dir}/webserver-default-namespace.cdl"/> <validate-cddlm file="${valid.dir}/documented.cdl"/> <validate-cddlm file="${valid.dir}/references-1.cdl"/> <validate-cddlm file="${valid.dir}/references-2.cdl"/> <validate-cddlm file="${valid.dir}/references-3.cdl"/> <validate-cddlm file="${valid.dir}/expression-1.cdl"/> <validate-cddlm file="${valid.dir}/type-1.cdl"/> <validate-cddlm file="${valid.dir}/lazy-1.cdl"/> <validate-cddlm file="${valid.dir}/lazy-2.cdl"/> <validate-cddlm file="${valid.dir}/parameterization-1.cdl"/> <validate-cddlm file="${valid.dir}/full-example-1.cdl"/> <validate-cddlm file="${valid.dir}/full-example-2.cdl"/> <validate-cddlm file="${valid.dir}/full-example-3.cdl"/> </target>
i just ran into this problem too: <http://marc.theaimsgroup.com/?l=ant-user&m=116653702922966&w=2> i've got a slow workaround using 2 optional tasks, jing and ant-contrib: <http://marc.theaimsgroup.com/?l=ant-user&m=116654529803752&w=2> it amounts to what steve loughran suggested in comment 3, but works with a fileset. i've just tried this again with ant 1.7.0 (released today), and the problem still exists. adding: <attribute name="http://xml.org/sax/features/validation" value="false" /> to xmlvalidate does not help. although most errors do not stop validation (with lenient="true"), dtd lookups still do, eg: <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <!DOCTYPE frameME SYSTEM "nasty.dtd"> dies with: /nasty.xml:123: Could not validate document nasty.xml Caused by: java.io.FileNotFoundException: nasty.dtd (No such file o r directory) resolveEntity: 'null': 'file:nasty.dtd' No matching catalog entry found, parser will use: 'nasty.dtd' is there a way to switch off dtd loading? why does it need it when validation is set to false? the xmlvalidate documentation is misleading-- it leads one to believe that lenient="true" will do well-formedness checking only. (from my current understanding of well-formedness, this goes beyond that.) - p
This bug hit me when trying to execute <xmlvalidate> behind a web proxy. Even though "lenient" is set to true, the task will still fail if the DTD (which is ignored anyway, AFAIK) cannot be downloaded. There are a number of workarounds when trying to use xmlvalidate behind a web proxy: 1. Download the DTD locally and define as a <dtd> in the task 2. Use the -autoproxy option for Ant (which I couldn't get working with Eclipse) 3. Use the <setproxy> task to manually set the proxy within Ant See: http://www.jevon.org/wiki/Disabling_DTD_validation_for_Ant_xmlvalidate_task_within_Eclipse
(In reply to comment #5) > the task will still fail if the DTD (which is > ignored anyway, AFAIK) cannot be downloaded. If the document has a DOCTYPE but you do not wish to validate against DTD, you can define a catalog which has an entry with that public ID but an empty body. The XML spec mandates that the DTD be retrieved even when not validating, since it can affect the infoset. (This is one compelling reason to switch to Schema or RELAX-NG.)