| 
  
  
     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. 
    
  
 |