Ability to reuse an existing coverage reports for Flex projects

We are also seeing this issue. Setting sonar.dynamicAnalysis to reuseReports does not work with a sonar.language of flex.

<sonar.language>flex</sonar.language>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis><sonar.cobertura.reportPath>$

</sonar.cobertura.reportPath>
<sonar.surefire.reportsPath>$

</sonar.surefire.reportsPath>

Might be useful : https://docs.sonatype.org/display/FLEXMOJOS/Test+coverage+support

Flexmojos 4.x has some nice coverage support but is still missing some essential goals from previous versions of FlexMojos (i.e. flexbuilder).

Vincen,

Thank you for the notification, but I've already created issue for integration with Flexmojos 4.x - SONARPLUGINS-667.
I've tried to use flexmojos-maven-plugin 4.0-alpha-6, but unsuccessfully. So, I don't think that we should try to integrate it right now - it's better to wait official release.
Moreover flexmojos 4.x requires Maven 3.x, but Sonar didn't support it yet.

Even though flex mojos will support test coverage I think it's still important to support the reusing of reports (especially surefire and cobertura, but pmd, cpd and ncss would be nice bonus).

Why? Well, many flex projects use Ant and generate surefire / pmd reports already (i'm looking on how to get cobertura working too). It would be very nice if those projects could use all features of this very cool Sonar plugin! I.e. let the plugin use the reports available instead of generating them. This would be more efficient as the reports don't have to be regenerated. By allowing configuration like Vincen described in it's first comment this would be possible.

Much more Flex projects could benefit this way. (Just add a small sonar pom with reuse reports config).

Arnoud

Hi Arnoud,

I perfectly understanding your motivation for reusing reports, but have a look to the following ticket to understand why we have started to depreciate all mechanisms to import existing reports : SONAR-1873

Hi Evgeny,

Thanks for the fast reply!

I looked at the issue you mentioned and understand the reasons for removing sonar.reuseExistingRulesConfiguration. But I don't understand why this is considered the same as reusing reports. So yeah, I definitely agree that rules should be managed in Sonar and that you want to manage the quality profiles in sonar too. This is described in the issue you mentioned. But I think this is a different issue (or maybe i just don't understand it ).

Let me explain:
Suppose that vanilla flex-mojos (without sonar) generates a cobertura.xml report. That will be the same as the one generated by Sonar using flex-mojos, right? But after this step the processing (sonar rules + standard reports = advanced quality control) takes place. At least this is how I understand it.

Why then reusing standardized reports like cobertura and surefire could be any harm or break consistency I fail to understand. (pmd is a different story as it has rules as input, which you probably want to manage / control in the sonar IDE).

all the best,

Arnoud

Correct – I too don't see how removing the ability to reuse unit test and coverage reports will cause problems with consistency.

Josh

Hi guys,

Sorry - that was my mistake : reuse of rules configuration was deprecated, but not reuse of coverage reports. So we can implement this feature.

I also want this feature in the Flex plugin for Sonar. In the meantime I have modified the original plugin so that it adds this support. I have used the the latest code for the flex plugin (sonar-flex-plugin-0.3.1) and the source from the cobertura plugin (sonar-cobertura-plugin-2.4.1). It is not much, it is just a small modification in the cobertura source files as I followed what was done with surefire to make this. I am attaching binary and also source files. I don't think it is the best solution, but it is more like a workaround while an official release appears. I will post some instructions on how to use it later today or tomorrow on my blog (http://tgeorgiev.blogspot.com), you can check it.

Tony

Hi Tony,

Could you please provide real patch for trunk version instead of full sources? In this case it would be much easy to review and integrate.

Hi Evgeny,

My bad, I am providing the patch against the trunk version

Hi Tony,

I reworked your patch in order to not duplicate code from Sonar Cobertura Plugin - r3587. Could you please provide example of Cobertura report for Flex project to test this implementation?

Hi Evgeny,
I am really glad that things are going on. I am attaching the Flex test project and the Cobertura coverage.xml that was generated from it. It should display 66% coverage for BasicArithmeticOperations class

Best

Not very clear for me - why provided report mentions files with extension ".java", whereas should be ".as" and ".mxml" ?
However I've added unit test - r3595.
So could you please try to use version from trunk?

I have tried but it seems that the Cobertura Sensor doesn't execute. I assume that also the Cobertura handler has to be added to the list of extensions in FlexPlugin.java

As for the coverage.xml, it is not clear to me also, as it is generated by FlexMojos. I assume that it is like that to keep consistency. However it does not interfere with the report

If you talk about MavenPluginHandler, then you're wrong, because it's used for Maven plugin execution, but we talk about report reuse mode.

Seems that I know why Sensor not executed - I'll take some time tomorrow to investigate this. Any way thanks for your help.

Fixed in r3599.

Awesome – THANKS guys! I'm looking very forward to reusing Cobertura reports for flex!

So can I use Cobertura for Flex now? Is this fixed in 0.4? If so, can you provide some sample config? I have tried using flexmojos 4.x <coverage>true</coverage> but this generates a parse exception as follows:

net.sourceforge.cobertura.javancss.parser.ParseException: Encountered " "<" "< "" at line 1, column 1.
Was expecting one of:

"abstract" ...
"class" ...
"enum" ...
"final" ...
"import" ...
"interface" ...
"native" ...
"package" ...
"private" ...
"protected" ...
"public" ...
"static" ...
"strictfp" ...
"synchronized" ...
"transient" ...
"volatile" ...
";" ...
"@" ...
"@" ...
"@" ...
"@" ...
"package" ...

at net.sourceforge.cobertura.javancss.parser.JavaParser.generateParseException(JavaParser.java:10296)
at net.sourceforge.cobertura.javancss.parser.JavaParser.jj_consume_token(JavaParser.java:10172)
at net.sourceforge.cobertura.javancss.parser.JavaParser.CompilationUnit(JavaParser.java:455)
at net.sourceforge.cobertura.javancss.parser.JavaParser.parse(JavaParser.java:137)
at net.sourceforge.cobertura.javancss.Javancss._measureSource(Javancss.java:256)
at net.sourceforge.cobertura.javancss.Javancss._measureRoot(Javancss.java:339)
at net.sourceforge.cobertura.javancss.Javancss.(Javancss.java:419)
at net.sourceforge.cobertura.reporting.ComplexityCalculator.getAccumlatedCCNForSource(ComplexityCalculator.java:102)

Hi,
This was implemented in 0.4 and was tested with Flex Mojos 3.6.1.
If you have problems, then please switch to users mailing list in order to investigate them.