Support multiple sourcesPaths

[pfrank13]

I'm not even sure this is possible given I know very little about Cobertura and even less about how reports are generated but currently the project only supports a single sourcesPath, however many project types on the JVM can mix source types, e.g. src/main/{java,groovy}, support for such hybrid projects would be very nice.

[pawlakm]

Hi, this would indeed be a nice feature. I'm not sure how to implement it. This will depend on the languages that are supported by cobertura. There is another feature that is in the backlog that aims at merging existing reports (generated by other plugins for languages that are not directly supported by cobertura) In all cases I won't have much time to work on it in the next few weeks. So if anybody wants to discuss this then contribute, help is appreciated. Michel

…

Le 17 mai 2017 à 01:42, Peter Frank ***@***.***> a écrit : I'm not even sure this is possible given I know very little about Cobertura and even less about how reports are generated but currently the project only supports a single sourcesPath, however many project types on the JVM can mix source types, e.g. src/main/{java,groovy}, support for such hybrid projects would be very nice. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pfrank13]

So I did a quick POC to add support for this using a tag called sourcesSets and just consumed that change in my project for groovy and java and it worked fine, sadly I think it exposed that Cobertura doesn't like Java 8 isms very much, which is another issue outside of your project. If you do know a workaround I'm all ears though cause I like what you have here! =) At this point I'm looking at Atlassian Clover.

As far as making sure Cobertura supports a given language to add a "seatbelt" for this plugin, I feel like that's on the developer to know and understand. At best you could point people to Cobertura docs to see what they support because enforcing it from just a string value in config would be impossible.

The only reason I needed another path is because I used GMavenPlus Maven Plugin for my groovy stuff, which keeps groovy in it's own source directory. If I were using Eclipse's Groovy plugin that wouldn't be idiomatic, the default is to have Groovy live alongside java files. Seems like an impossible task at the qualinsight plugin layer of abstraction to enforce but that's just my thought.

If you'd like me to do a PR with a sourcesSets tag I'd be happy too if it seems like a sane approach for the project, if not no big deal =)

Thanks for the quick replies!

[pfrank13]

#43 is the PR for this if you're interested

[pawlakm]

Hi again, thanks for your contribution. I'll have a closer look at it and will update the example projects to make sure that everything works fine.

My first feedback is that your PR is a good start, however it won't be sufficient as is: the convertReport method and AbstractCleaningReportMojo class will need to be modified as well.

Back to your question about Java 8 support, that's indeed a well known issue. Cobertura does not support it yet, and it seems that its development is stalled (last PR merged in July 2016, no development for the last year, lots of PRs are waiting for approval)

My recommendation would be to use Jacoco if you want to use Java 8.

Michel

[pfrank13]

Oh crap, sorry I missed that, I didn't check all the usages of sourcesPath, whoops. I'll take a crack at supporting multiple paths in covertReport.

Jacoco is what I usually use but unfortunately it doesn't have any support for Groovy, it doesn't bomb or anything but the output certainly doesn't make a whole lot of sense. The Groovy Language site pointed to Cobertura as the only library that supports Groovy. Atlassian Clover (which was recently open sourced) seems my only other choice to support both Java and Groovy. However, it's not a huge ask to just not use method references or other Java 8 isms it doesn't support, I believe that's what's slipping it up in my project which is almost all Groovy.

[pfrank13]

Didn't have time to take a real crack at the report bit today but it looks like it's going to get dicey since the Cobertura XML coverage file doesn't maintain a reference to what source directory it came from in it's XML file, so that has to be driven by the CoberturaToSonarQubeCoverageReportConverter code in some way.

I want to look into how the HTML Cobertura generates figures out where things came from because I would think it would encounter the same sort of problem but I suppose it can be rendered via an entirely different set of context objects.

[pfrank13]

@pawlakm, I'm no XSL expert but I can't see a way to support multiple source sets without checking for the existence of the file at just before or at render time, see my commit message above.

Can XSL support that kind of thing, or better yet, is that an approach worth pursuing with XSL?

To me checking the existence of a file is something that needs to live outside of a template, and if that's the case I'd rather just render the XML via JAXB. What're your thoughts?