Some source files here definitely use Hamcrest, so listing it as a
dependency seems reasonable. What I find confusing is the inconsistency
among my Eclipse installations. On some of my various machines, Eclipse
reports an error if this dependency is not listed. On others, Eclipse
finds the required jar and reports no error, even if this dependency is
not listed. I don't know why the latter works, or why the inconsistency
exists at all. Eclipse is a complex, subtle beast. What I can say is
that this change fixes the error for my Eclipses that were reporting an
error, and does not introduce any new errors for my Eclipses that were
already happy before this change.
When Maven generates these "*/target/antrun/build-main.xml" Any build
scripts, it does not include any DTD or XML Schema declarations.
Eclipse's XML validator warns about the lack of grammar constraints.
The warning is sensible, but we are not in a position to do anything
about it. Better, therefore, to suppress these warnings so that we
can more-clearly see warnings we *can* address.
We actually know the full grammar for these files: it is documented at
<http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fplugin_manifest.html>.
We ought to be able to extract that DTD into a file and give each
"plugin.xml" a "<!DOCTYPE plugin SYSTEM ...>" declaration referencing
it. Unfortunately, that leads to a new warning: "External entity
resolution is not supported by PDE." So a stub declaration is the
best we can do. Fortunately, Eclipse's structured editor seems to
preserve these once we add them by hand.
Some of these might have proper DTDs or XML Schema definitions
floating around somewhere that we could use. Presumably many do not.
Rather than hand-craft such definitions myself, I'm just giving each a
minimal stub DOCTYPE declaration. That's enough to satisfy Eclipse's
XML validator, which otherwise complains that these files lack grammar
constraints.
I think the "target/p2artifacts.xml" and "target/p2content.xml" files
are generated by Maven. They are well-formed XML but Eclipse's XML
validator legitimately warns that they lack grammar constraints.
Since we're not maintaining the tool that creates these files, we are
not in a position to do anything about that. Therefore, we may as
well exclude these from validation entirely. That way we can
more-clearly recognize warnings that we *can* do something about.
In theory, these files could be checked against the DTD given at
<http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Ffeature_manifest.html>.
In practice, Eclipse's structured editor for this file type discards
any "<!DOCTYPE ...>" declarations one might manually add. So there's
no convenient way to tell Eclipse' XML validator what grammar to use.
Fortunately, that same structured editor makes it unlikely that anyone
will introduce invalid content. So I don't mind excluding these files
from XML validation entirely.
Eclipse's XML validator warns about missing grammar constraints in
several XML files that come from non-WALA projects. We are not in a
position to do anything about these problems.
Ant "build.xml" files don't have a standard DTD or XML Schema; the
contents are simply too flexible for that. But we can at least
give each a stub DOCTYPE declaration. That's enough to satisfy
Eclipse's XML validator, which otherwise complains that these files
lack grammar constraints.
As created by Tycho Surefire, these files are XML documents without
DTD or XML Schema declarations. The XML validator warns about this
omission. However, Surefire is not a WALA component. We are not in a
suitable position to change it to include XML schema or DTD
declarations in the XML files it generates. Better, then, to ignore
this benign problem so we can focus on warnings that we can act on
directly.
Most of the invalid HTML arose from bare "<" and ">" characters.
These should be escaped as "<" and ">" when not intended to
introduce HTML tags. When you have many such characters close
together, "{@literal ...}" is a nice, readable alternative that
automatically escapes its contents. If the text in question is
intended to be a code fragment, then "{@code ...}" is appropriate:
this is essentially equivalent to "<code>{@literal ...}</code>".
There were a few other HTML violations too, but none common enough to
be worth detailing here.
The contents of @author go straight into HTML, just like most other
Javadoc material. So if you want to have a "<foo@bar.com>" e-mail
address as part of the author information, the angle brackets must be
escaped. Here I've opted to do that using "{@code <foo@bar.com>}",
which has some additional styling effects that seem appropriate for
e-mail addresses. We could also have used "<foo@bar.com>" for
escaping without code styling.
It's unclear whether the original authors of these pages intended them
to be valid or invalid. Certainly there is merit in testing against
invalid HTML, since the vast majority of real-world HTML is indeed
invalid. I'm going to assume that any errors in this collection of
test inputs are intentional, and therefore not worth reporting when
running Eclipse HTML validation.
Plugin documentation includes plenty of invalid HTML. However, we
don't maintain these files, so we are not in a position to fix them.
Better, therefore, to suppress these warnings so that we can notice
and fix other problems over which we do have control.
It's unclear whether the original authors of these pages intended them
to be valid or invalid. Certainly there is merit in testing against
invalid HTML, since the vast majority of real-world HTML is indeed
invalid. I'm going to assume that any errors in this collection of
test inputs are intentional, and therefore not worth reporting when
running Eclipse HTML validation.
Eclipse validation warns about invalid HTML content in all
Maven-generated "target/site/dependency-convergence.html" files. The
warnings are legitimate: these HTML files are indeed invalid.
However, we don't maintain the tool that generates these files, so we
are not in a position to fix them. Better, therefore, to suppress
these warnings so that we can notice and fix other problems over which
we do have control.
Manu Sridharan
Martin Mohr
Julian Dolby
Ben Liblit