For all examples the analyse.xml script that comes with the distribution was adapted for the example and both the unmodified and metachecked results are shown.
Within the unmodified results you will see 3 types of results: plain text results, results in one xml file and files in some directory structure. Note that the jcsc pages are almost identical to that of the results after running metacheck, metacheck borrowes their elegant method of saving and presenting results.
The metachecked results after running metacheck. Notice the uniform (jcsc-like) styled results and the added meta result pages.
As a first example of metachecks capabilities it seems apropriate to run metacheck on metacheck itself leading to the following results:
As a first test on an alien application, maven-1.0.2 was metachecked. Maven is used in for generating documentation, building and may get a plugin sometime in the (near) future. After some minor modification to the analyse.xml script all except hammurapi were working (hammurapi appears somewhat picky on classpath dependencies), with the following results:
It must be noted that the default configuration of the various code checkers was used to run the code checker. These default configs usually find very many violations some with 'trivial' or 'debatable' rules. For a real project these configs should be changed to suit your needs.
Occasionally rules of 2 or more code checkers may be in conflict, so whatever the code, one or another violation will be found. For example the rules about naming conventions (uppercase, lowercase, underscores, etc) and constructor rules (empty constructor mandatory or not).
The results of metacheck show a large number of violations, one may wonder how well metacheck itself is in it's own terms. It was decided not change metacheck because violations were found (unless the violation points to a rule that indicated a possible error condition). Although it's very tempting to do so, then metacheck would no longer be good example/test project for itself.