You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've have been using Cobertura via maven site goal for very long time and maven-site-plugin is nothing but trouble. Our project are large with many different dependencies, with many jar including different version of libraries like Guava, etc.
The maven-site-plugin seems to load plugins and dependencies into class path differently, which causes all kinds of random build failures while doing static code analysis. The normal build (mvn clean install) will pass, but mvn site will fail.
For this reason I really wanted to be able to wire cobertura into normal build life cycle. Turns out that we can already wire the instrument goal, but not the report generation (cobertura.ser --> cobertura.xml) that can be consumed by the Jenkins plugin. Adding new generate-report goal allowed me to wire Cobertura directly into build (mvn clean install).
I added this new generate-report a while back and it has been working rather good. There was some projects with our custom OSGI plugins that I had to exclude because I couldn't figure out what is the problem. Also because Cobertura actually modified the target class path in the maven environment I had to also add this 'hack' to maven-bundle-plugin.
The text was updated successfully, but these errors were encountered:
Added generate-report goal that can be used as part of normal build.
Using maven-site-plugin to generate cobertura was causing all kinds of
weird dependency issues so we need alternative means of generating the
cobertura.xml report. The report is generated based on previously
generated cobertura.ser file that is created by calling
cobertura:instrument first.
I've have been using Cobertura via maven site goal for very long time and maven-site-plugin is nothing but trouble. Our project are large with many different dependencies, with many jar including different version of libraries like Guava, etc.
The maven-site-plugin seems to load plugins and dependencies into class path differently, which causes all kinds of random build failures while doing static code analysis. The normal build (mvn clean install) will pass, but mvn site will fail.
For this reason I really wanted to be able to wire cobertura into normal build life cycle. Turns out that we can already wire the instrument goal, but not the report generation (cobertura.ser --> cobertura.xml) that can be consumed by the Jenkins plugin. Adding new generate-report goal allowed me to wire Cobertura directly into build (mvn clean install).
I added this new generate-report a while back and it has been working rather good. There was some projects with our custom OSGI plugins that I had to exclude because I couldn't figure out what is the problem. Also because Cobertura actually modified the target class path in the maven environment I had to also add this 'hack' to maven-bundle-plugin.
The text was updated successfully, but these errors were encountered: