[Maven-plugins-developer] [ maven-plugins-Bugs-1387499 ] [cobertura] Using aspectj maven plugin con

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Bugs item #1387499, was opened at 2005-12-21 14:47
Message generated for change (Comment added) made by jeffjensen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1387499&group_id=61626

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: cobertura
Group: release
Status: Pending
Resolution: None
Priority: 5
Submitted By: psylence (psylence)
Assigned to: Jeff Jensen (jeffjensen)
Summary: [cobertura] Using aspectj maven plugin confuses cobertura

Initial Comment:
When compiling sources with an overridden java:compile
goal like so:

<preGoal name="java:compile">
  <attainGoal name="aspectj:compile"/>
</preGoal>

(as recommended from:
http://maven.apache.org/maven-1.x/reference/plugins/aspectj/index.html

The cobertura plugin compiles the source twice, once
correctly, then instruments it.  It then gets to the
test:test goal, at which time it compiles the source
again, and copies it over the already instrumented
code.  The result is 0 coverage.

The JCoverage maven plugin handles this without issue.
 The major difference I can see is the following from
the reporting goals of the two plugins:

cobertura:report

  <goal name="cobertura:report">
    .. snip ..
          <attainGoal name="cobertura:on"/>
          <attainGoal name="test:test"/>

jcoverage:report-html

  <goal name="jcoverage:report-html"
prereqs="jcoverage:on,test:test">

Apparently maven considers java:compile as having been
run when jcoverage:on is ran as a prereq?  Not sure,
but moving the cobertura:on,test:test into a prereq for
cobertura:report ends in an error.

----------------------------------------------------------------------

>Comment By: Jeff Jensen (jeffjensen)
Date: 2006-08-02 06:15

Message:
Logged In: YES 
user_id=498804

Thanks for testing those things.

For your "First off," case, you would have had to modify the
Cobertura plugin's POM as you did before, so the plugin
would run with the 1.8 version (your project's dependencies
do not affect the plugins').  You would have also had to
change your project's POM to depend on the prior Cobertura
plugin version (you probably did this, but want to make
sure!) and set the datafile property.  Would you mind doing
that test case please?  We still need to eliminate the other
1.2 plugin changes as a problem.

Also, when you run Maven, please use the "-e" argument to
get the exception trace.  e.g. "maven -e clean cobertura"

I deployed 1.3-snapshot with the plugin.jelly fix you tried
and that another user found fixed their problem.  That is
the only change so far.  You may want to try with it
too/make it the base for our efforts.  Remote repo is
maven.plugins.sf.snapshots.

Is it possible for you to create something for me to run
locally?  Just the simplest POM and example class(es) to
reproduce what you see; should help speed things along for
us.  If so, just zip and attach to this issue.

----------------------------------------------------------------------

Comment By: Markus Mathis (mmathis76)
Date: 2006-08-02 03:15

Message:
Logged In: YES 
user_id=1565970

Jeff,

I'm sad to say that neither of your previous 
recommendations seems to work in our specific case.

First off, I modified /home/maven/tmp/phr-
usermgnt/project.xml to contain the following dependecy 
for cobertura 1.8.

        <dependency>
            <groupId>cobertura</groupId>
            <artifactId>cobertura</artifactId>
            <version>1.8</version>
        </dependency>

Then I executed "maven clean" and invoked "maven 
cobertura:report" for the project again.
Still the respective web page is reporting 0 % coverage.

Therefore, I tried your second suggestion by 
editing /home/maven/.maven/cache/maven-cobertura-plugin-
1.2/plugin.jelly.
I replaced   <goal name="cobertura:report" 
description="Generate test coverage reports with 
Cobertura"> with <goal name="cobertura:report" 
prereqs="cobertura:on,test:test"> and removed the tags 
<attainGoal name="cobertura:on"/> and <attainGoal 
name="test:test"/>.

After cleaning up the project and invoking "maven 
cobertura:report", Maven is failing now due to 
an "internal error". Please note that the exceptions after 
aspectj:compile were also present before my latest 
modifications but they never made "maven cobertura:report" 
fail in the first place:
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.1-beta-2

build:start:

java:compile:
phr:init:
    [copy] Copying 9 files to /home/maven/tmp/phr-
usermgnt/src/gen/META-INF

aspectj:init:

aspectj:compile:
    [iajc] /home/maven/tmp/phr-
usermgnt/src/main/com/icw/phr/usermgnt/setup/UsermgntDataRe
ader.java:56 [warning] Exception swallowed in catch block 
[Xlint:swallowedExceptionInCatchBlock]
    [iajc] } catch (IOException e) {
    [iajc]                 // ignore
    [iajc]             }
    [iajc]                         
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    [iajc] /home/maven/tmp/phr-
usermgnt/src/main/com/icw/phr/usermgnt/setup/UserRepository
DataSetup.java:94 [warning] Exception swallowed in catch 
block [Xlint:swallowedExceptionInCatchBlock]
    [iajc] } catch(Exception e) {
    [iajc]              // User not found
    [iajc]         }
    [iajc]                      
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    [iajc]
    [iajc] 2 warnings
    [iajc] Copying 7 files to /home/maven/tmp/phr-
usermgnt/target/classes

INTERNAL ERROR
Reference made to goal 'java:compile' which has no 
definition.

----------------------------------------------------------------------

Comment By: Jeff Jensen (jeffjensen)
Date: 2006-08-01 23:04

Message:
Logged In: YES 
user_id=498804

One more thing Markus, if none of the prior ideas work, then
please change these in the plugin.jelly:
from: 
  <goal name="cobertura:report">

to:
  <goal name="cobertura:report"
prereqs="cobertura:on,test:test">

and remove these lines:
  <attainGoal name="cobertura:on"/>
  <attainGoal name="test:test"/>

Test it and see if it works!  A prior user reported this
makes it work.  I think this is what we need to do.  If that
works, I'll create an official snapshot and we can formally
test.

----------------------------------------------------------------------

Comment By: Jeff Jensen (jeffjensen)
Date: 2006-08-01 08:07

Message:
Logged In: YES 
user_id=498804

Hi Markus, Thank you for trying those things.

Please try one more change:
Since you modified the plugin in your local repo for the
property, could you leave that change in place and change
the pom to depend on the cobertura >= 1.7?

I want to eliminate a 1.2 change to maven.cobertura.datafile
as the cause, and these two things together will test that.
 If it works with your modified way, then we know the fix. 
If not, then we (obviously!) need to diagnose further.

One further thought is the notes in another bug:
1517491
https://sourceforge.net/tracker/index.php?func=detail&aid=1517491&group_id=61626&atid=497853

It looks like something we need to investigate.  If you have
ideas to further that research, please do!  :-)

Note that this bug entry has a problem: we can't edit
anything on it, including adding a comment.  I have reported
it to SF support, but they have not fixed it yet.

----------------------------------------------------------------------

Comment By: Markus Mathis (mmathis76)
Date: 2006-08-01 04:06

Message:
Logged In: YES 
user_id=1565970

Jeff,

First of all thanks for your reply to my recent post to 
the cobertura-devel list.

Well, I modified /home/maven/.maven/cache/maven-cobertura-
plugin-1.2/plugin.properties as recommended. Now, 
maven.cobertura.datafile is pointing to 
${basedir}/cobertura.ser instead of 
=${maven.cobertura.dir}/cobertura.ser. However, the 0% 
coverage issue still persists.

As far as the other option you mentioned (downgrading to 
cobertura plugin 1.1.1) is concerned, it didn't work 
properly and I didn't really expect it to do so. If I get 
everything right, aspectj support is in fact a feature of 
cobertura >= 1.7. Whereas maven cobertura plugin 1.1.1 
relies upon cobertura 1.6.

    [cobertura-instrument] Instrumenting 65 classes 
to /home/maven/tmp/phr-usermgnt/target/cobertura/classes
    [cobertura-instrument] Exception in thread "main" 
java.lang.IllegalArgumentException: Unknown attribute 
type: org.aspectj.weaver.MethodDeclarationLineNumber
    [cobertura-instrument]      at 
org.objectweb.asm.Attribute.a(Unknown Source)
    [cobertura-instrument]      at 
org.objectweb.asm.MethodWriter.a(Unknown Source)
    [cobertura-instrument]      at 
org.objectweb.asm.ClassWriter.toByteArray(Unknown Source)
...
BUILD FAILED

Please let me know, if there are any other workarounds I 
could try anf if you need any other information to track 
down the issue.

Best regards,

Markus

> Hi,
>
> It looks like you fixed the first problem with the multi-
source directories.
>
> The Maven 1 Cobertura plugin is hosted at SourceForge 
here:
>  http://maven-plugins.sourceforge.net/maven-cobertura-
plugin/index.html
>
> I think this defect is for this issue you experience:
> https://sourceforge.net/tracker/index.php?
func=detail&aid=1387499&group_id=61626&atid=497853
> Could you post your info there and work with me to solve 
this problem please?
> In the defect linked above, I posted a few things to 
try, but have not heard back from the original reporter.
> I would appreciate you > doing those and replying on 
that thread.
>
> If your issue is different, please create a new bug 
entry there and we will work on it from there.

>> System setup:
>> - maven:
>> *maven-1.1-beta2
>> - aspectj:
>> *maven-aspectj-plugin-3.2_p2
>> * aspectjrt-1.5.0.jar
>> * aspectjrt-1.5.1.jar
>> * aspectjtools-1.5.0.jar
>> * aspectjtools-1.5.1.jar
>> - cobertura:
>> *maven-cobertura-plugin-1.2
>> * cobertura-1.6.jar
>> * cobertura-1.8.jar
>>
>> Problem Description:
>> (1) Projects which don't use aspectj compiled code 
produce correct line coverage / branch coverage reports 
via the web interface
>> (2) Projects which use aspectj compiled code FAIL to 
produce correct line coverage / branch coverage reports
>>
>> Some snippet from our project.xml
>> ...
>> <build>
>> ...
>> <sourceDirectory>${basedir}/src/gen</sourceDirectory>
>> <sourceDirectory>${basedir}/src/main</sourceDirectory>
>> ...
>> < build>
>> ...
>>
>> When running maven cobertura:report from the command 
line and opening the respective result page in a browser, 
I get the following >> result: Unable to locate 
com/icw/phr/usermgnt/service/CrudService.java. Have you 
specified the source directory?"
>>
>> At first I suspected that multiple source directories 
(see above!) were somehow confusing maven / cobertura. 
(Please note that I >> came across a preconfigured maven 
project setup. So changing the way maven is configured 
isn't really an option here.)
>>
>> I tried the following workaround in maven.xml to make 
maven (version 1.1) handle several source directories:
>>
>>         <goal name="set-java-compile-src-set">
>>                 <ant:path id="src.dirs">
>>                      &nbs p;  <ant:pathelement 
path="${basedir}/src/main"/>
>>                         <ant:pathelement 
path="${basedir}/src/gen"/>
>>                 </ant:path>
>>                 <maven:addPath 
id="maven.compile.src.set" refid="src.dirs"/>
>>                 <ant:property name="maven.src.dirs" 
refid="maven.compile.src.set"/>
>>                 
<ant:echo>maven.compile.src.set=${maven.src.dirs}
</ant:echo>
>>         </goal>
>>
>>         <preGoal name=" cobertura:report">
>>         <attainGoal name="set-java-compile-src-set"/>
>>         </preGoal>
>>
>> In so doing the "Unable to locate ..." problem was 
solved but Cobertura is still displaying 0% Line / Branch 
Coverage.
>>
>> I'm not quite sure if the aforementioned issue is due 
to the way the source directories are organized or if 
there is a general
>> problem with aspectj and cobertura (>= 1.7).
>>
>> Any feedback and suggestions by the authors of 
cobertura would be greatly appreciated. Are there any 
references / best practise
>> cases for using the maven-cobertura-plugin along with 
aspectj compiled source code?

----------------------------------------------------------------------

Comment By: Jeff Jensen (jeffjensen)
Date: 2006-07-29 21:59

Message:
Logged In: YES 
user_id=498804

1. Which cobertura version is everyone using that exhibits
this problem - is everyone on 1.2?

2. Does this problem occur with version 1.1.1 of the plugin?

3. With version 1.2, set maven.cobertura.datafile to basedir
and try again, like this:
  maven.cobertura.datafile=${basedir}/cobertura.ser

Please try 1.1.1 and the property change with 1.2 and reply
with your results!

----------------------------------------------------------------------

Comment By: Krystian Nowak (krystian_nowak)
Date: 2006-07-05 08:14

Message:
Logged In: YES 
user_id=1294218

could be duplicated by bug [ 1517491 ] cobertura.ser does
not exis
(https://sourceforge.net/tracker/index.php?func=detail&aid=1517491&group_id=61626&atid=497853)

----------------------------------------------------------------------

Comment By: stephane bouchet (le_phan)
Date: 2006-03-07 09:22

Message:
Logged In: YES 
user_id=572945

hi, having the same issue. 

Using maven 1.1-beta2, jdk 1.5, aspectj-plugin 3.3 SNAPSHOT
 and cobertura 1.2 SNAPSHOT. 

I had all my reports to 0%

modified the cobertura:report has mantionned ( add prereqs )
and everything worked.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1387499&group_id=61626

[Maven-plugins-developer] [ maven-plugins-Bugs-1387499 ] [cobertura] Using aspectj maven plugin con

[Maven-plugins-developer] [ maven-plugins-Bugs-1387499 ] [cobertura] Using aspectj maven plugin confuses cobertura