On 8/28/07, Erik Ramfelt <
[hidden email]> wrote:
> On 8/23/07, Peter Reilly <
[hidden email]> wrote:
> > It would be easy to add support for different
> > violation types:
> > One needs to write two classes:
> > * a parser that understands the format of the report xml file
> > and converts it to a standard violations format
> > see for example h.p.v.parse.CheckstyleParser
> > * a descriptor class that has the name of the violation type,
> > the parser and optionally a violation code to extreme
> > detailed description.
> > see for example h.p.v.parse.FindBugsDescriptor
> > and modify h.p.v.TypeDescriptor to add the new descriptor.
>
> Yesterday I started parsing a FxCop log and I got a few questions on
> how it works.
>
> The first entries in the FxCop log contains issues/violations for the
> DLL (as FxCop always reads the output and not the source files). This
> is of course a binary and I wonder if there will be a problem using
> binary files in FullFileModel?
Yes. The code will try to display the dll!!
>
> As FxCop works against the compiled files, they sometimes do not
> contain file paths or file row. The information I can get out all the
> time is the name of the namespace, class and method/property/parameter
> names. I guess this is quite different from the other reports as they
> are file based. Does this make it impossible to parse violations in
> fxcop reports? Or could I just convert the code info into a file name
> and continue? (I tried yesterday but it complained that one file did
> not exist).
Check the findbugs parser, It is given the name of the class and line
numbers within the corresponding source file. If the class file
is not compiled with debug information, the parser converts the
classname to a corrsonding .java file and searches the source directories
for the corresponding file.
>
> Or would it be possible to add a different type for file model that
> contains class information instead of file information? (I guess that
> would require quite some job?)
>
> As I was unsure how the parsing was done, I created a small unit test
> that would parse simple bits of a FxCop report. But I had problems
> understanding how I could access the violations from a FullBuildModel.
> How should I do something like this?
> assert.areEqual(2, fullBuildModel.getViolationsForFile("aaaaaa.cs"))
I have not looked into this yet.. (on my todo list....)
>
>
> On another note, I checked out what pylint/pychecker gives out. They
> can only report into a so called "parseable" format that isnt XML. I
> was going through the code and the AbstractParser seems to be XML
> orientated, is there any interface that a pylint parser could
> implement?
>
> Example:
> src/python/tvguicontroller.py:176: [R,
> TvGuiController.__create_show_context_menu] Method could be a function
> src/python/tvguicontroller.py:176: [W,
> TvGuiController.__create_show_context_menu] Unused argument 'gui'
I am changing the Descriptor so that the parser does not need to
be xml based.
the new signature is:
public abstract ViolationsParser createParser();
and ViolationsParser is:
public interface ViolationsParser {
/**
* Parse a violations file.
* @param model the model to store the violations in.
* @param projectPath the project path used for resolving paths.
* @param violationsFile the name of the violations file to parse
* (relative to the projectPath).
* @param sourcePaths a list of source paths to resolve classes against
* @throws IOException if there is an error.
*/
void parse(
FullBuildModel model,
File projectPath,
String fileName,
String[] sourcePaths)
throws IOException;
}
Peter
>
>
> Cheers
> //Erik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
[hidden email]
> For additional commands, e-mail:
[hidden email]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
[hidden email]
For additional commands, e-mail:
[hidden email]
