#26 More structure and detail in xml output

release_2.3
closed
nobody
None
5
2012-10-10
2002-01-30
Rob Oxspring
No

It would be good if the xml output were grouped into
packages and possibly include a little more
information. Ideally I would like to see something
along the lines of the following to allow simple
presentation through xslt. (I'm not that interested in
the absolute file name and so used the short version)

<checkstyle>
<package name="abc">
<file name="MyClass.java">
<error .../>
</file>
<file ...>
<file ...>
</package>
<package ...>
<file ...>
<file ...>
</package>
</checkstyle>

It might also be nice if the line containing the error
were extracted too - possibly with some context.

Rob

Discussion

  • Oliver Burn
    Oliver Burn
    2002-01-30

    Logged In: YES
    user_id=218824

    That is a good idea - it would make it much easier to
    create output with metrics based on package (like JUnit
    reports).

    An issue with implementing this is that the files are
    checked in what ever order they are based in. If files come
    in different order (not a problem with ANT I hope), then
    unless Checkstyle sorts all output first, the output will
    be inconsistent.

    A simple approach could be to group the order like:

    <checkstyle>
    <directory>
    <file ...>
    <file ...>
    </directory>
    ....
    </checkstyle>

    This approach would:
    1) Only require changes to the XMLLogger
    2) Handle the case code for the same package in is multiple
    directories. As an example checkstyle put the test code in
    the same package, in another directory.

     
  • Rob Oxspring
    Rob Oxspring
    2002-02-25

    Adds package information to XML output

     
  • Rob Oxspring
    Rob Oxspring
    2002-02-25

    Logged In: YES
    user_id=314769

    Here's a patch aimed at adding a package attribute to the
    xml output. Additionally the xsl now summerises by package
    too.

    The code is a bit messy but I couldn't work out how to add
    it in otherwise.

    Rob

     
  • Rob Oxspring
    Rob Oxspring
    2002-02-25

    Logged In: YES
    user_id=314769

    By the way, this completely ignores the ordering/grouping
    problem at the xml level in favour of xsl. A grouped
    approach would make much nicer xsl but I don't know my way
    around the code enough just now. Regarding the grouping -
    personally speaking the package is all that interests me
    but I see your point about the directory.

    Rob

     
  • Oliver Burn
    Oliver Burn
    2002-05-26

    Logged In: YES
    user_id=218824

    Rob,

    I apologise for not applying this patch already. I just noticed
    today that you had submitted a patch. I will apply it before the
    next release.

    Oliver

     
  • Oliver Burn
    Oliver Burn
    2002-09-03

    Logged In: YES
    user_id=218824

    added support for basedir

     
  • gui
    gui
    2003-01-06

    Logged In: YES
    user_id=681786

    Hello all,

    I have checked the source and apparantly this feature is not
    yet incorporated in the current (2.4) version. I it rejected ? I
    think 'package browsing' a la javadoc would be however a
    good improvement.

    I'm deciding whether to use checkstyle or jcsc for code style
    checking. Checkstyle seems to have the best features, but the
    reporting is weak compared to that of jcsc.

    Is there no quick way to get rid of the (in our case very long)
    absolute path names in the files ?

    Thanks

     
  • Oliver Burn
    Oliver Burn
    2003-01-09

    Logged In: YES
    user_id=218824

    Just to clarify that we did not incorporate the entire
    patch. The support for the basedir property was
    taken/inspired by your patch. However after much thought we
    did decided to not implement the support for package
    browsing. The main reasons being:

    • the default output of Checkstyle should be focused on the
      file locations and not logical packages

    • to implement the solution properly would require caching
      all the errors in memory for sorting. This would have an
      impact for large amounts of errors (on 1 project I hit
      100,000 errors). There may be ways around this.....

    • time. We have been focused heavily on version 3 of Checkstyle.

    Please take the time to look at the upcoming version of
    Checkstyle.. I think you will be impressed with the new
    framework and all the new features (yes lots more!). You
    should be able to extend Checkstyle by writing your own
    logger to support your required functionality. If you do,
    please let us know.

     
  • Oliver Burn
    Oliver Burn
    2003-01-09

    Logged In: YES
    user_id=218824

    and to clarify. Using the basedir property it is very easy
    to reduce very long absolute file names.

     
  • Rob Oxspring
    Rob Oxspring
    2003-01-09

    Logged In: YES
    user_id=314769

    If I understand the latest code (presumably v3 dev) then
    the AuditEvents still don't supply the package
    information. IMHO it is crazy to have to guess / infer
    the package name from the filename when the (accurate)
    declaration is there in the source. If this information
    were available then I'd be very happy.

     
  • Oliver Burn
    Oliver Burn
    2003-01-09

    Logged In: YES
    user_id=218824

    Initially I thought the package name was available as well.
    However, there are the cases where

    • The file cannot be parsed and we still need to report an error

    • Checks are performed that do not care about package names.
      For example, verifying a file ends with a newline. Or the
      more advanced example is checking the contents of resource
      property files.

    Further, with the new architecture of plug-in checks, there
    is no obvious way to ensure the package name is known before
    Checks start logging errors. For example, we have a check
    that verifies that source files begin with a specified header.

    So I share your desire to have the information - it is just
    not a trivial exercise to get it. Hence why it has not been
    done. there are other lower hanging fruit.