Hi David,

this is an excellent idea. Judging from your example XML, the crap4j XML report contains a lot more information (see example snippet below).
So i don't think it's the best way to transform the Crap4Net XML (and make up a lot of information).
In fact, extending the crap4j plugin data model shouldn't be that hard and you/we only need to make up the parts that are really needed.

If you like, I would assist your effort with some guidance for the existing code and the hudson development details, if necessary. Time's a bit short for me, but weekends should be fine.

Example XML for crap4j:
<crap_result>
<some tags here/>
<stats>
...
</stats>
<methods>
<method>
<package>
com.schneide.display
</package>
<className>
ControlCode
</className>
<methodName>
<init>
</methodName>
<methodSignature>
(Ljava/lang/String;)V
</methodSignature>
<fullMethod>
public void <init>(java.lang.String)
</fullMethod>
<crap>
1.00
</crap>
<complexity>
1
</complexity>
<coverage>
100.00
</coverage>
<crapLoad>
0
</crapLoad>
</method>
<method>
<package>
com.schneide.display
</package>
<className>
DisplayFactory
</className>
<methodName>
createDisplayFor
</methodName>
<methodSignature>
(Lcom/schneide/display/data/EFirmwareVersion;ILcom/schneide/display/model/IStreamPair;)Lcom/schneide/display/Display;
</methodSignature>
<fullMethod>
public static com.schneide.display.Display createDisplayFor(com.schneide.display.data.EFirmwareVersion, int, com.schneide.display.model.IStreamPair)
</fullMethod>
<crap>
1.00
</crap>
<complexity>
1
</complexity>
<coverage>
100.00
</coverage>
<crapLoad>
0
</crapLoad>
</method>
</methods>
</crap_result>

Hi David,

i couldn't resist to check the current codebase. The immediate extension point in the code seems to be the interface hudson.plugins.crap4j.model.IMethodCrap
From this type, four methods aren't used yet, it boils down to this:

public interface IMethodCrap {

public abstract String getPackageName();

public abstract String getClassName();

public abstract String getMethodName();

public abstract String getMethodSignature();

/* Not used */
public abstract String getFullMethod();

/* Not used */
public abstract double getCrap();

/* Not used */
public abstract double getComplexity();

/* Not used */
public abstract double getCoveragePercent();

public abstract int getCrapLoad();
}

This might be directly mappable from your data base, given that the conversion crap --> crapLoad is possible without further values.

Subclassing this type to read from Crap4Net's XML instead of Crap4J's seems to be the first step for me.

dlinder,

Thanks for your quick response and helpful comments.

I've been speaking with Lior (who wrote Crap4Net); he has agreed to extend Crap4Net to output in the Crap4J format.

If we can't get as much info as Crap4J, then I might follow up your idea on subclassing IMethodCrap to read Crap4Net's format.

I've assigned this ticket to myself; I'll follow up with a patch or further questions.

dlinder,

Lior has extended Crap4Net so that it outputs reports in the same format as Crap4J; and these are successfully parsed by Hudson/Crap4J.

I'd like to verify that we're getting all the information correct for Hudson Crap4J plugin to display - can you point me at a Hudson Job that is using the Crap4J plugin successfully?

Thanks

David