Sonar Plugins

Support reusing EMMA 2.0 reports that were generated by Android SDK

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: EMMA-1.2.1
  • Fix Version/s: None
  • Component/s: Emma
  • Labels:
    None
  • Environment:
    Sonar 2.8, Android SDK r12, Win2k8, Ant 1.8, Java 1.6
  • Patch Submitted:
    Yes
  • Number of attachments :
    2

Description

When analyzing an Android project, the latest upgrade of EMMA 2.0 to 2.1 breaks the ability to reuse the generated EMMA coverage reports. In fact what happens is that the build simply fails as soon as the EMMA plugin tries to load the files.

Unfortunately it's not an easy task to upgrade EMMA inside the Android SDK and therefore it would be nice to have some automatic transcoding of EMMA 2.0 files to be able to work with Android Projects again (and still have the latest plugin version in use).

As I couldn't wait for a solution to be provided, I analysed the differences between EMMA-20 and EMMA-21 file formats and created a small transcoder that I use during the ANT build (see attached files).
While this is a working solution (and maybe also a workaround for those that found this tracker case), it would really make life easier when the transcoding step could be added to the EMMA plugin.

Important Note: I'm not transcoding EMMA files in place. Instead they are copied into a temp folder first to avoid that EMMA (from Android SDK) complains about an invalid file format, the next time a build runs.

  1. File
    EmmaTranscoder.class
    06/Sep/11 8:44 AM
    4 kB
    Juergen Kellerer
  2. Java Source File
    EmmaTranscoder.java
    06/Sep/11 8:44 AM
    5 kB
    Juergen Kellerer

Issue Links

is duplicated by

New Feature - A new feature of the product, which has yet to be developed. SONARPLUGINS-2146 Emma - can't use old binary format

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Evgeny Mandrikov added a comment -

Hi Juergen,

Couple of questions in order to just clarify situation :

There is no ability to use something else than Emma with Android SDK? E.g. Cobertura or JaCoCo? If so, then what's a shame. I'm asking this, because Emma is dead (latest release was 6 years ago - 2005) and so we don't want to invest a lot of time into support of a dead tool.

If I correctly understand from a code of your transcoder - there is no difference between formats 2.0 and 2.1 except of metadata, i.e. no difference in coverage data?

Show
Evgeny Mandrikov added a comment - Hi Juergen, Couple of questions in order to just clarify situation : There is no ability to use something else than Emma with Android SDK? E.g. Cobertura or JaCoCo? If so, then what's a shame. I'm asking this, because Emma is dead (latest release was 6 years ago - 2005) and so we don't want to invest a lot of time into support of a dead tool. If I correctly understand from a code of your transcoder - there is no difference between formats 2.0 and 2.1 except of metadata, i.e. no difference in coverage data?
Hide
Permalink
Juergen Kellerer added a comment - - edited

Hi Evgeny,

To answer your questions directly, it may be that you can use other tools, but it won't be easy and it definitively won't be the standard.
The simple solution was to convert the file format as there are no other changes than the ones you already found yourself. (I use it in production now and it works as stable as other coverage tools)

The issue with Android is that it ships with EMMA 2.0 and Unit tests run inside the Emulator with a "patched" version of the jar. (There is emma.jar, emma-ant.jar and an emma-device.jar which is the patched one, I think). To be honest I haven't tried to replace this as I didn't wanted to start creating my own patched jars from a dead project (as you also stated) and anyway I doubt that replacing this jar would do the trick.

The runtime behaviour with Android is that everything is compiled into "classes.dex" (also the jars you depend on), then packaged in an APK (=jar-like but containing classes.dex as a single file) and transferred to the emulator that is running as a virtual device. Tests are packaged as a separate APK depending on the first one.
After the test-app ran through you can use a commandline tool (through ANT) to transfer the generated files back to your local HDD. (e.g. copy coverage.ec from /data/..../yourapp/test/coverage.ec => C:\somepath).
All of this is hidden behind ANT tasks and pre-installed build scripts that do most of these things.

Because everything wires up inside the SDK and the pre-installed build scripts, it's much more effort to try to get other tools integrated and it has to be done with every new module that you start.

To me it was just more efficient and logical to do this transcoder, which enabled me to reuse what is generated by default from the latest SDK using more or less the default ANT target that already ships with it. (The only remaining customization that I have to do is avoiding that the *.ec and *em files are cleaned after generating the HTML report)

Show
Juergen Kellerer added a comment - - edited Hi Evgeny, To answer your questions directly, it may be that you can use other tools, but it won't be easy and it definitively won't be the standard. The simple solution was to convert the file format as there are no other changes than the ones you already found yourself. (I use it in production now and it works as stable as other coverage tools) The issue with Android is that it ships with EMMA 2.0 and Unit tests run inside the Emulator with a "patched" version of the jar. (There is emma.jar, emma-ant.jar and an emma-device.jar which is the patched one, I think). To be honest I haven't tried to replace this as I didn't wanted to start creating my own patched jars from a dead project (as you also stated) and anyway I doubt that replacing this jar would do the trick. The runtime behaviour with Android is that everything is compiled into "classes.dex" (also the jars you depend on), then packaged in an APK (=jar-like but containing classes.dex as a single file) and transferred to the emulator that is running as a virtual device. Tests are packaged as a separate APK depending on the first one. After the test-app ran through you can use a commandline tool (through ANT) to transfer the generated files back to your local HDD. (e.g. copy coverage.ec from /data/..../yourapp/test/coverage.ec => C:\somepath). All of this is hidden behind ANT tasks and pre-installed build scripts that do most of these things. Because everything wires up inside the SDK and the pre-installed build scripts, it's much more effort to try to get other tools integrated and it has to be done with every new module that you start. To me it was just more efficient and logical to do this transcoder, which enabled me to reuse what is generated by default from the latest SDK using more or less the default ANT target that already ships with it. (The only remaining customization that I have to do is avoiding that the *.ec and *em files are cleaned after generating the HTML report)

People

  • Assignee:
    Unassigned
    Reporter:
    Juergen Kellerer
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: