<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I've reported the bug Karel mentioned and if interested, you can find more details here: <a href="http://jira.codehaus.org/browse/MCOMPILER-216">http://jira.codehaus.org/browse/MCOMPILER-216</a></div><br><div><div>On Oct 8, 2013, at 12:57 PM, Karel Piwko <<a href="mailto:kpiwko@redhat.com">kpiwko@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi All,<br><br>here are the details of the story:<br><br>We have some unit tests written in Java and integration tests written in<br>Groovy. We collect results using Jacaco in "appending" mode. That means we are<br>able to run unit tests with instrumented code and integration tests with<br>instrumented AS JVM. Then we can merge results together or not, depends on what<br>we want.<br><br>So, where are the problems with Groovy compiler? Simply, it generates a<br>different bytecode than Javac. So, when running integration tests, we are<br>constructing microdeployments, that contain classes or archives, deploy them to<br>AS, using what's available on classpath or in Maven repositories (or, Maven<br>Reactor for multimodule projects). And we actually need those classes to be<br>compiled by the *same* compiler all the time so jacoco can match results.<br><br>So, what are the options?<br><br>1/ Use groovyc to compile all the code we need to instrument. However, that<br>means that we would need to change remote repository to a proxy repository where<br>binaries are build via groovy and rebuild all aerogear with groovy before code<br>coverage gathering happens. I did that for the first round of CC results, and<br>it was simply a too much mess to cope with despite the fact that I skipped<br>workaround for Maven and thus I got I bit underestimate results.<br><br>2/ Use javac everywhere. So, we need to remove groovy.<br><br>3/ Use groovyc to compile only tests. This unfortunately does not work, as<br>maven-compiler-plugin ignores includes/excludes. Tadeas can provide<br>upstream issue #. Moreover, it takes *years* to get something fixed in Maven.<br><br>4/ Migrate to Gradle, where include/exclude might work correctly<br><br>So, the option is 2/.<br><br>Karel<br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote></div><br></body></html>