In general, test code may do all sorts of things that would be
considered poor style in production code. I assume that these
potentially-static methods are declared non-static by design.
These should mostly be things that we've already decided earlier that
we explicitly don't want to "fix" because they simply disagree with
the WALA project's coding style.
The additional diagnostics are ones that were previously being
ignored, but which we seem to have been ignoring by default rather
than as a conscious choice.
For diagnostics of which we currently have *zero* instances, treat
these as errors rather than merely warnings. The intent is to
permanently lock out future regressions of things we've completely
fixed. In the future, whenever we fix the last instance of a given
warning in a given Eclipse project, we should also promote that
diagnostic to an error to keep things clean into the future.
The Eclipse IDE shows no such diagnostics, so it would be nice to
treat them as errors if any appear in the future. However, the batch
Tycho-based build ("mvn clean install -DskipTests") does find and
report numerous such violations. This discrepancy is strange; Manu
and I currently don't know why it's happening. We suspect some
Maven-related weirdness may be creating slightly different
environments in the Eclipse GUI versus the command-line-driven build.
* Fix pom.xml to be like other projects
* Check for existence of nodejs download before re-downloading
* Fix Eclipse config files to be like other projects
This fixes one Eclipse "The JRE container on the classpath is not a
perfect match to the 'JavaSE-1.7' execution environment" warning in
the "Plug-in Development" category.
This fixes five Eclipse "Source folder '...' does not have the output
folder in corresponding output entry 'output..'" warnings in the
"Plug-in Development" category.