<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi David,<br>
Please don't remove the failOnValidationError door! <br>
<br>
I'm using it to handle test books for OpenStack, which only include
one file at a time (and therefore have link issues). This allows a
much faster way to check editing layout (using OpenStack branding).<br>
<br>
thanks, Summer<br>
<br>
<div class="moz-signature">
<div><font color="#666666">Summer Long<br>
OpenStack Documentation<br>
Engineering Content Services<br>
<br>
Red Hat Asia Pacific<br>
Brisbane, Australia</font><br>
<a href="mailto:slong@redhat.com">slong@redhat.com</a></div>
</div>
<br>
<span style="color:#000000;" class="headerSpan">
<div class="moz-cite-prefix">On 07/19/2013 06:22 AM, David Cramer
wrote:<br>
</div>
</span>
<blockquote cite="mid:51E84E6F.2000805@rackspace.com" type="cite">
<pre wrap="">On 07/18/2013 03:08 PM, Lorin Hochstein wrote:
</pre>
<blockquote type="cite">
<pre wrap="">David:
Yes, the validation script are only looking at individual files right
now, which is why they don't catch missing cross-references.
I agree that maven would be better for gating. But maven isn't currently
gating, is it?
</pre>
</blockquote>
<pre wrap="">
Now that I think of it more, Maven is the only thing that can really
validate this because you might have a file that's valid on the file
system but invalid after profiling:
Say you have <section xml:id="foo" condition="rhel">...</section> and
elsewhere <xref linkend="foo"/>. When you build validate with your
script, all is well because the IDREF linkend="foo" matches
xml:id="foo", but if you build with profileCondition=ubuntu, that
section is removed and you have a broken link.
The build will blow up if there's an IDREF without a matching ID in the
document UNLESS failOnValidationError=no.
As of 1.6.x, Maven validates the doc twice: first after resolving
xincludes it validates without checking IDREFs, then again towards the
end after all profiling etc, it checks IDREFs as well. This is to catch
the situation where the doc was valid but was made invalid by filtering
out content. In 1.8.0, I give you a more helpful error message that
suggests opening an intermediate file in the target dir and validating
it so you can see the actual error (line numbers are meaningless since
the original source file has been manipulated by resolving xincludes etc).
Does that make sense?
If leaving the failOnValidationError=no door available is a bad thing, I
could easily make it so failOnValidationError is ignored if
branding=openstack. Or perhaps Jenkins could pass in
failOnValidationError=yes, which would override what's in the pom (or
some other trick to make sure Jenkins never builds something where
validation doesn't kill the build).
David
_______________________________________________
Openstack-docs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openstack-docs@lists.openstack.org">Openstack-docs@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a>
</pre>
</blockquote>
<br>
</body>
</html>