Introducing jacoco.exec files on Hudson: easy-to-use coverage results
by Mickael Istria
Hi all,
As tracked by https://issues.jboss.org/browse/JBIDE-10537 , we are
aiming to support Jacoco for code coverage. Jacoco [1] is a very nice
and easy to set up coverage tool that has no significant impact (in our
use-case) on performance [2] , and that only requires a system
property[3] or a maven plugin to set it up in your build [4]. It
requires no instrumentation, so it does not requires additional step in
build workflow to get results.
Jacoco's only current drawback is it's missing integration with Jenkins
[5], but as soon as this is available, we will fully drop support for
all the emma stuff to move to Jacoco.
Waiting for this Jacoco-Jenkins integration, I set up the Maven plugin
in parent and Hudson jobs so that test execution produce a jacoco.exec
file. This file is archived in your build result along with the output
update-site.
See [6] for examples. It is set up for all components jobs on Trunk. If
you don't see this on your job that means that you did not run a build
since this was changed, just start a build to see the jacoco.exec file
in the end.
If you want to have local report, then run "mvn clean install" (or
anything that works and runs tests) in your local component module.
Ensure you are up-to-date with build/ and your-component/ first.
This jacoco.exec file is pretty easy for you to consume. You can import
it in Eclipse using EclEmma plugin [7] (see [8] for how-to) and you'll
get reports in a dedicated view and also directly on your source code
editor. Beware that your jacoco.exec files has coverage support for the
latest test execution, so file that change it may be inaccurate when
dealing with files that have changed in your workspace since jacoco.exec
was generated.
Please add feedback to JBIDE-10537
[1] http://www.eclemma.org/jacoco/
[2] http://www.sonarsource.org/pick-your-code-coverage-tool-in-sonar-2-2/
[3] http://www.eclemma.org/jacoco/trunk/doc/agent.html
[4] http://www.eclemma.org/jacoco/trunk/doc/maven.html
[5] https://issues.jenkins-ci.org/browse/JENKINS-10835
[6]
http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job...
[7] http://www.eclemma.org/installation.html#updatesite
[8] http://www.eclemma.org/userdoc/importexport.html
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
12 years, 8 months
Update manifest.mf file for nested dependencies against juno
by Rob Stryker
Hi All:
I've added a section to this wiki page
(https://community.jboss.org/wiki/HowToBuildJBossToolsWithMaven3#Tips_and_...)
describing the issue, but, to summarize it, all compile time
dependencies must now be explicitly declared in your manifest.mf if you
expect your plugin to build against juno.
While investigating /JBIDE-11545, we discovered archives.ui built fine
against indigo, but failed against juno. The reason was that archives.ui
had a compile-time dependency on org.eclipse.ui.views, but the
manifest.mf did not declare this dependency. The dependency was resolved
fine in the past because archives.ui depended on org.eclipse.ui.ide, and
org.eclipse.ui.ide depended on org.eclipse.ui.views.
It seems tycho will no longer resolve nested dependencies. If you have a
compile time dependency on a plugin or bundle, you must declare it
explicitly in your manifest.mf. You can no longer trust that tycho will
be able to resolve these nested dependencies and provide all available
plugins at build time.
This will be a huge pain for some people. I know in my dev style, I
just try to implement an interface, and, if eclipse does not resolve it,
then I add it to manifest.mf. It seems to me that doing so now will
maybe cause errors and broken builds for devs who do not build locally
before every commit. If for example you try to implement an interface,
and eclipse does not complain, it is likely that a plugin you already
depend on also provides you access to the interface you are seeking. But
when building in tycho against juno, this plugin won't be found.
So update those manifest.mf files, and if you haven't been building
locally for every commit, start doing it, at least for compilation.
12 years, 8 months