Open markcraig opened 8 years ago
Workaround:
Build the docs, e.g. mvn site
, and then validate the file in IntelliJ in the built docs, e.g. target/docbkx-sources/<docname>/index.xml
. This should display the error.
When xIncludeAware is set, the only file the Linktester sees is going to be index.xml, all the xIncluded files will be automagically expanded by the XML parser and that is going to be completely transparent. I guess one solution around that would be to print out the name of the parent chapter, but not sure how effective could that be. I suppose an alternative would be to run linktester against the chapter files only (i.e. not against the book index.xmls) and disable xIncludeAware? There is a good chance then that would miss some generated files though...
We have a lot of spurious errors in our files since we moved to <xref>
from <link>
for all links local to the document. Documents are often made up of dozens of files.
An <xref> linkend
attribute value is an xml:id
value, and so only valid inside a file.
On one hand, our abuse is relatively benign because docbook-linktester
will catch the <xref>
errors that are real errors: the errors that are still not resolved when the whole document is brought together after the XIncludes are resolved.
On the other hand, our abuse is insidious because it kind of prevents file-by-file checking.
I'm not sure there's an easy fix for this one, unless there's some way of knowing the filename even after you've XIncluded everything.
At present
docbook-linktester
logs the top-level document name, e.g. index.xml, when it finds an XML error. The writer then has to build the pre-processed docs and perform validation again in the IDE to find the actual location of the error.It would be nice if
docbook-linktester
could log the name of the actual file that led to the error.