On 01/07/2014 07:16 PM, Igor Fedorenko
wrote:
Can
you explain your overall development flow? Specifically, why
eclemma
"sees" both the original and pack200 normalized versions of the
same class?
I'm running tests with Tycho surefire. Those tests depend on some
bundles available in repositories. Those bundles are the one that
I'd like to get coverage metrics on.
In their repositories, those bundles are both available as plain
jars and as pack200 artifacts. Tycho (p2) always fetches the pack200
artifacts and unpack them, which is a good choice for performance.
Test runs against those unpack200'd jars and JaCoCo reports are
generated against the output of unpack200.
EclEmma runs against the plain classes as they are produced by JDT.
The class manipulation done by pack200/unpack200 makes that EclEmma
can't match classes as defined in reports with classes and sources
as they are in IDE.
See https://github.com/jacoco/eclemma/issues/49
If I could get directly the plain jars instead of the pack200 ones,
EclEmma would be able to match stuff.
When I use a local install of those jars (former "mvn install")
everything is fine as Tycho uses the plain jar. I can see coverage
in EclEmma.
Not saying Tycho doesn't need the option to ignore pack200
artifacts,
just curious why you need it.
Actually, IMO the root cause is that composing pack200 and unpack200
leads to classes that are different from the ones originally
created. That really surprised me, and I now hate pack200 for that.
So I'm looking for workarounds, and I thought be able to enforce
usage of plain jars instead of pack200 in Tycho would help, although
it's not a perfect solution.
|