Menu
▾
▴
maven-plugins-developer — Mailing List used for development of plugins
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(14) |
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(14) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2004 |
Jan
(4) |
Feb
(8) |
Mar
(14) |
Apr
(18) |
May
(1) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(5) |
Oct
(26) |
Nov
(36) |
Dec
(21) |
| 2005 |
Jan
(10) |
Feb
(20) |
Mar
(15) |
Apr
(11) |
May
(29) |
Jun
(18) |
Jul
(19) |
Aug
(12) |
Sep
(11) |
Oct
(3) |
Nov
(7) |
Dec
(5) |
| 2006 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(14) |
Jul
(45) |
Aug
(58) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2007 |
Jan
(4) |
Feb
|
Mar
|
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2006-08-05 13:01:47
|
Bugs item #1534206, was opened at 2006-08-03 17:38 Message generated for change (Comment added) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1534206&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: tasks Group: release >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Jeff Jensen (jeffjensen) Assigned to: Jeff Jensen (jeffjensen) Summary: [tasks] repeats prior section's data with M1.1 Initial Comment: A subsequent category or subcategory repeats the prior one's last row repeatedly down the page in the subsequent entries. The entry count is correct, but instead of the true data displaying for each entry, it displays that prior one. It corrects itself when changing levels, e.g. from a subcategory to a category section. ---------------------------------------------------------------------- >Comment By: Jeff Jensen (jeffjensen) Date: 2006-08-05 08:01 Message: Logged In: YES user_id=498804 Fix committed to 1.3 thanks to Lukas... jsl needed change from string(.) to string($task) to work. We went a step further and changed it to <jsl:applyTemplates select="$task"/> to allow pass through, which enables HTML in the task now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1534206&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-04 11:51:57
|
Bugs item #1387499, was opened at 2005-12-21 21:47 Message generated for change (Comment added) made by mmathis76 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: Open 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: Markus Mathis (mmathis76) Date: 2006-08-04 13:51 Message: Logged In: YES user_id=1565970 (1) cd /home/maven/.maven/cache/maven-cobertura-plugin-1.2 (the "default location") I modified plugin.properties in order to contain maven.cobertura.datafile=${basedir}/cobertura.ser (2) The effect of this setting seems to be project-specific. If I leave it in my own project.properties file, maven.cobertura.check.report will fail or hang up, thus producing weird results for the reports. (e.g. the coverage reports for the individual classes were correct while the aggregated values for the packages were at 0%.) BTW: One colleague was able to use the aforementioned setting for one project but had to remove it for another one. (3) As I said, I just changed the sequence for my "multiple source directory" workaround to <preGoal name="cobertura:report"> <attainGoal name="set-java-compile-src-set"/> </preGoal> <preGoal name="java:compile"> <attainGoal name="set-java-compile-src-set"/> </preGoal> and added <attainGoal name ="cobertura:on"/> and <attainGoal name ="cobertura:off"/> to the <preGoal name="test:test"> respectively <postGoal name="test:test"> of our HSQLDB Lifecycle test. As for your 1.3 snapshot, I didn't try it yet. But, to be honest, I don't want to temper with a working installation. ;-) ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-08-03 18:15 Message: Logged In: YES user_id=498804 Great! You are welcome; glad we could get it to work. Thanks for your persistence in testing and trying things. Would you mind posting here precisely (e.g. code snippets) the configs you have for this to work? So far, your testing says we must have: 1. maven.cobertura.datafile=${basedir}/cobertura.ser (the default location does not work, right? did you test without this setting but with the other changes?) The user should set this in their own project.properties file. 2. set maven.cobertura.check.report=false (I wonder why you had to disable that report?! Do you have an idea why? Perhaps there is something in it to change so it too will work...) The user should set this in their own project.properties file. 3. maven.xml <pregoal> settings (can you share them so we can add to the web site notes?) >From your info, let's add notes to the site docs for us to document what is necessary to run with AspectJ. I will make any other necessary mods to the 1.3 snapshot plugin and publish again for you to verify. When that works, we can officially release the 1.3 plugin and publish the site with the notes. Did you try the 1.3 snapshot with the prereq change? Did that make it work on its own? If not, can you try it with the things you know have made it work, one at a time? ---------------------------------------------------------------------- Comment By: Markus Mathis (mmathis76) Date: 2006-08-03 17:19 Message: Logged In: YES user_id=1565970 Hi Jeff, Thanks for putting things clear concerning the plugin settings. I followed your recommendations this time but still cobertura (plugin version 1.1.1) wouldn't work. Then, I upgraded to 1.2 again and tried a couple of other things: The combination of setting maven.cobertura.datafile to ${basedir}/cobertura.ser, some pregoal sequence changes in the project's maven.xml file and removing maven.cobertura.check.report=true from the project.properties finally did the trick. Thanks again for your support. ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-08-02 13: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 10: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-02 06: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 15: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 11: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-30 04: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 15: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 16: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 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 22:38:33
|
Bugs item #1534206, was opened at 2006-08-03 17:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1534206&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: tasks Group: release Status: Open Resolution: None Priority: 8 Submitted By: Jeff Jensen (jeffjensen) Assigned to: Jeff Jensen (jeffjensen) Summary: [tasks] repeats prior section's data with M1.1 Initial Comment: A subsequent category or subcategory repeats the prior one's last row repeatedly down the page in the subsequent entries. The entry count is correct, but instead of the true data displaying for each entry, it displays that prior one. It corrects itself when changing levels, e.g. from a subcategory to a category section. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1534206&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 16:15:13
|
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: Open 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-03 11:15 Message: Logged In: YES user_id=498804 Great! You are welcome; glad we could get it to work. Thanks for your persistence in testing and trying things. Would you mind posting here precisely (e.g. code snippets) the configs you have for this to work? So far, your testing says we must have: 1. maven.cobertura.datafile=${basedir}/cobertura.ser (the default location does not work, right? did you test without this setting but with the other changes?) The user should set this in their own project.properties file. 2. set maven.cobertura.check.report=false (I wonder why you had to disable that report?! Do you have an idea why? Perhaps there is something in it to change so it too will work...) The user should set this in their own project.properties file. 3. maven.xml <pregoal> settings (can you share them so we can add to the web site notes?) >From your info, let's add notes to the site docs for us to document what is necessary to run with AspectJ. I will make any other necessary mods to the 1.3 snapshot plugin and publish again for you to verify. When that works, we can officially release the 1.3 plugin and publish the site with the notes. Did you try the 1.3 snapshot with the prereq change? Did that make it work on its own? If not, can you try it with the things you know have made it work, one at a time? ---------------------------------------------------------------------- Comment By: Markus Mathis (mmathis76) Date: 2006-08-03 10:19 Message: Logged In: YES user_id=1565970 Hi Jeff, Thanks for putting things clear concerning the plugin settings. I followed your recommendations this time but still cobertura (plugin version 1.1.1) wouldn't work. Then, I upgraded to 1.2 again and tried a couple of other things: The combination of setting maven.cobertura.datafile to ${basedir}/cobertura.ser, some pregoal sequence changes in the project's maven.xml file and removing maven.cobertura.check.report=true from the project.properties finally did the trick. Thanks again for your support. ---------------------------------------------------------------------- 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 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 15:19:34
|
Bugs item #1387499, was opened at 2005-12-21 21:47 Message generated for change (Comment added) made by mmathis76 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: Markus Mathis (mmathis76) Date: 2006-08-03 17:19 Message: Logged In: YES user_id=1565970 Hi Jeff, Thanks for putting things clear concerning the plugin settings. I followed your recommendations this time but still cobertura (plugin version 1.1.1) wouldn't work. Then, I upgraded to 1.2 again and tried a couple of other things: The combination of setting maven.cobertura.datafile to ${basedir}/cobertura.ser, some pregoal sequence changes in the project's maven.xml file and removing maven.cobertura.check.report=true from the project.properties finally did the trick. Thanks again for your support. ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-08-02 13: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 10: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-02 06: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 15: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 11: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-30 04: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 15: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 16: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 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 14:56:32
|
Feature Requests item #1533935, was opened at 2006-08-03 09:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1533935&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: tasks Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Jensen (jeffjensen) Assigned to: Jeff Jensen (jeffjensen) Summary: [tasks] Create XSD for tasks.xml Initial Comment: Create a schema so we can validate it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1533935&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 14:52:33
|
Feature Requests item #1533931, was opened at 2006-08-03 09:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1533931&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: tasks Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Jensen (jeffjensen) Assigned to: Jeff Jensen (jeffjensen) Summary: [tasks] Add a "Priority" column Initial Comment: Add a priority column to the tasks report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1533931&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 14:36:59
|
Feature Requests item #1533916, was opened at 2006-08-03 09:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1533916&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: tasks Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Jensen (jeffjensen) Assigned to: Jeff Jensen (jeffjensen) Summary: [tasks] Move more significant columns to first in order Initial Comment: Change column order in tasks-report.html to generally have most significant columns first. Suggested order: Task Status Effort Assigned To Creator Start End Version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1533916&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 12:48:51
|
Bugs item #1532794, was opened at 2006-08-01 17:41 Message generated for change (Comment added) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1532794&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: tasks Group: release >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Jeff Jensen (jeffjensen) >Assigned to: Jeff Jensen (jeffjensen) Summary: [tasks] Unrecognised tag: 'include' with M1.1 Initial Comment: Parse exception running M1.1: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'include' (position: START_TAG seen ...<resource>\n <include>... @47:26) See attached file for full info. ---------------------------------------------------------------------- >Comment By: Jeff Jensen (jeffjensen) Date: 2006-08-03 07:48 Message: Logged In: YES user_id=498804 This was already fixed in CVS by Carlos. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1532794&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 10:35:53
|
Bugs item #861603, was opened at 2003-12-17 12:11 Message generated for change (Comment added) made by wdsgoe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=861603&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: webtest Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Siegfried GOESCHL (wdsgoe) Summary: [webtest] fails when maven.webtest.ant.options is not set Initial Comment: my setup: maven-rc2-SNAPSHOT java 1.4.2 debian linux (unstable) webtest-plugin 0.8.1 I always got this error when I tried to execute my tests: <snip> [java] [java] BUILD FAILED [java] Target `' does not exist in this project. [java] <snip> After looking at the jelly-scripts of the webtest-plugin, I tried setting the maven.webtest.ant.options property (to -v) and it worked. Edmund em...@li... ---------------------------------------------------------------------- >Comment By: Siegfried GOESCHL (wdsgoe) Date: 2006-08-03 10:35 Message: Logged In: YES user_id=183881 Well, is fixed ages ago ---------------------------------------------------------------------- Comment By: Siegfried GOESCHL (wdsgoe) Date: 2006-08-03 10:35 Message: Logged In: YES user_id=183881 Well, is fixed ages ago ---------------------------------------------------------------------- Comment By: Siegfried GOESCHL (wdsgoe) Date: 2005-01-10 09:27 Message: Logged In: YES user_id=183881 I reintroduced this bug and will fix it again in the next release of the webtest plugin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=861603&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-03 10:35:43
|
Bugs item #861603, was opened at 2003-12-17 12:11 Message generated for change (Comment added) made by wdsgoe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=861603&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: webtest Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Siegfried GOESCHL (wdsgoe) Summary: [webtest] fails when maven.webtest.ant.options is not set Initial Comment: my setup: maven-rc2-SNAPSHOT java 1.4.2 debian linux (unstable) webtest-plugin 0.8.1 I always got this error when I tried to execute my tests: <snip> [java] [java] BUILD FAILED [java] Target `' does not exist in this project. [java] <snip> After looking at the jelly-scripts of the webtest-plugin, I tried setting the maven.webtest.ant.options property (to -v) and it worked. Edmund em...@li... ---------------------------------------------------------------------- >Comment By: Siegfried GOESCHL (wdsgoe) Date: 2006-08-03 10:35 Message: Logged In: YES user_id=183881 Well, is fixed ages ago ---------------------------------------------------------------------- Comment By: Siegfried GOESCHL (wdsgoe) Date: 2005-01-10 09:27 Message: Logged In: YES user_id=183881 I reintroduced this bug and will fix it again in the next release of the webtest plugin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=861603&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-02 11:15:39
|
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 |
|
From: SourceForge.net <no...@so...> - 2006-08-02 08:15:37
|
Bugs item #1387499, was opened at 2005-12-21 21:47 Message generated for change (Comment added) made by mmathis76 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: Markus Mathis (mmathis76) Date: 2006-08-02 10: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-02 06: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 15: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 11: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-30 04: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 15: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 16: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 |
|
From: SourceForge.net <no...@so...> - 2006-08-02 07:44:34
|
Feature Requests item #1220428, was opened at 2005-06-14 14:18 Message generated for change (Comment added) made by mdproctor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1220428&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: javaapp Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Proctor (mdproctor) Assigned to: Nobody/Anonymous (nobody) Summary: [javaapp] File concat, project exclusion, & jdk compat jars Initial Comment: take a look at 267. This is our Drools jar-all goal that builds a single jar for our multiproject. http://cvs.drools.codehaus.org/viewrep/drools/drools/maven.xml?r=1.53.2.11 The key difference is that we need to concatonate drools.conf files. We also exclude a build time dependency project as well as jdk1.5 projects. This is done using the property "drools.jdk5.projects", we hope to eventually have that controlled by the project properties maven.compile.source and maven.compile.target. We also plan to deploy two jar-all jars, one for jdk1.4 and one for jdk1.5. Would be great if we could dump the custom code and just use a single plugin for all of this. Mark Drools Project Lead. ---------------------------------------------------------------------- >Comment By: Mark Proctor (mdproctor) Date: 2006-08-02 07:44 Message: Logged In: YES user_id=40124 It's probably still a good idea. But we are no longer in need of this feature at the moment. ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-08-01 22:53 Message: Logged In: YES user_id=498804 HI Mark, are you still in need of this, or have you moved on?? ---------------------------------------------------------------------- Comment By: Mark Proctor (mdproctor) Date: 2005-06-14 14:26 Message: Logged In: YES user_id=40124 some ideas on how to do this. maven.javaapp.exclusion = <list of project names> (applies to all resulting jars) -This property could potentially be jdk specific too maven.javaapp.exclusion-jdk1.5 = <list of project names> (applies to the jdk1.5 compatible jar) maven.javaapp.exclusion-jdk1.4 = <list of project names> (applies to the jdk1.4 compatible jar) maven.javaapp.jdk-specific = <list of target jars> (1.4 1.5 - leave blank and it will just include all) maven.javaap.concat-text-files = <list of text files to be concatenated> Will also need a naming convention for jdk specific jars. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1220428&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-02 04:06:08
|
Bugs item #1104628, was opened at 2005-01-18 11:14 Message generated for change (Settings changed) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1104628&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: axis Group: release Status: Pending Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeff Jensen (jeffjensen) >Summary: [axis] single url (external) wsdl2java bug. Initial Comment: the jelly script detects single urls wrongfully. It might be me, since I'm fairly new to this, but there is no way it seems to generate the java stubs for a remote webservice on a remote host. The current way its written it triggers for single generation when the url property ends with .wsdl, hard to submit a remote url then :) Proposed patch is to detect if start of url starts with http ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-07-30 17:10 Message: Logged In: YES user_id=498804 Hi, I'd like to fix this for you and release a snapshot. Do you have a precise change(s) or patch to attach? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-01-18 11:16 Message: Logged In: NO Or even better patch... edit the wsdlPostfix property to have "wsdl" instead of ".wsdl" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1104628&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-02 04:05:28
|
Bugs item #1370823, was opened at 2005-12-01 05:44 Message generated for change (Settings changed) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1370823&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: sdocbook Group: release Status: Pending Resolution: None Priority: 5 Submitted By: Jean-Frans El Fouly (jfelfouly) Assigned to: Nobody/Anonymous (nobody) >Summary: [sdocbook] Images not included in generated PDF Initial Comment: While the setup seems correct and I have jimi 1.0 jar in my maven repository, I keep getting this error (while converting docbooks for the Scarab project): [java] [INFO] JAI support was not installed (read: not present at build time). Trying to use Jimi instead [java] Error creating background image: Error creating FopImage object (http://docbook.sourceforge.net/release/images/draft.p ng) : Jimi image library not available The build succeeds but I get PDF's without their images; HTML conversion works fine. ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-07-29 22:07 Message: Logged In: YES user_id=498804 I know it has been a number of months since you reported this, do you have any new info to report? E.g. does the problem still exist, or did you find the solution? I do not use this plugin, but will gladly help you to get it fixed if you can help diagnose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1370823&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-02 04:04:05
|
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-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 |
|
From: SourceForge.net <no...@so...> - 2006-08-01 22:53:15
|
Feature Requests item #1220428, was opened at 2005-06-14 09:18 Message generated for change (Comment added) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1220428&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: javaapp Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Proctor (mdproctor) Assigned to: Nobody/Anonymous (nobody) >Summary: [javaapp] File concat, project exclusion, & jdk compat jars Initial Comment: take a look at 267. This is our Drools jar-all goal that builds a single jar for our multiproject. http://cvs.drools.codehaus.org/viewrep/drools/drools/maven.xml?r=1.53.2.11 The key difference is that we need to concatonate drools.conf files. We also exclude a build time dependency project as well as jdk1.5 projects. This is done using the property "drools.jdk5.projects", we hope to eventually have that controlled by the project properties maven.compile.source and maven.compile.target. We also plan to deploy two jar-all jars, one for jdk1.4 and one for jdk1.5. Would be great if we could dump the custom code and just use a single plugin for all of this. Mark Drools Project Lead. ---------------------------------------------------------------------- >Comment By: Jeff Jensen (jeffjensen) Date: 2006-08-01 17:53 Message: Logged In: YES user_id=498804 HI Mark, are you still in need of this, or have you moved on?? ---------------------------------------------------------------------- Comment By: Mark Proctor (mdproctor) Date: 2005-06-14 09:26 Message: Logged In: YES user_id=40124 some ideas on how to do this. maven.javaapp.exclusion = <list of project names> (applies to all resulting jars) -This property could potentially be jdk specific too maven.javaapp.exclusion-jdk1.5 = <list of project names> (applies to the jdk1.5 compatible jar) maven.javaapp.exclusion-jdk1.4 = <list of project names> (applies to the jdk1.4 compatible jar) maven.javaapp.jdk-specific = <list of target jars> (1.4 1.5 - leave blank and it will just include all) maven.javaap.concat-text-files = <list of text files to be concatenated> Will also need a naming convention for jdk specific jars. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497856&aid=1220428&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-01 22:45:04
|
Patches item #1158946, was opened at 2005-03-08 04:47 Message generated for change (Settings changed) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497855&aid=1158946&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: javancss Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: [javancss] To execute the JAVANCSS in test and cactus... Initial Comment: the first change is : the goal maven-checkstyle-plugin:deregister in the jelly.plugin changed to maven-javancss-plugin:deregister the second change is : the addition of the registration of the JAVANCSS Test report and the JAVANCSS Cactus report the third change is : the addition of the de registration of the JAVANCSS Test report and the JAVANCSS Cactus report the fourth change is : the addition of the generation of the reports above mentioned changed proposed by RaphaPini rap...@ya... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497855&aid=1158946&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-01 22:41:46
|
Bugs item #1532794, was opened at 2006-08-01 17:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1532794&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: tasks Group: release Status: Open Resolution: None Priority: 8 Submitted By: Jeff Jensen (jeffjensen) Assigned to: Nobody/Anonymous (nobody) Summary: [tasks] Unrecognised tag: 'include' with M1.1 Initial Comment: Parse exception running M1.1: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'include' (position: START_TAG seen ...<resource>\n <include>... @47:26) See attached file for full info. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1532794&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-08-01 13:07:58
|
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: Using aspectj maven plugin confuses cobertura plugin 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-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 |
|
From: SourceForge.net <no...@so...> - 2006-08-01 09:06:06
|
Bugs item #1387499, was opened at 2005-12-21 21:47 Message generated for change (Comment added) made by mmathis76 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: Using aspectj maven plugin confuses cobertura plugin 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: Markus Mathis (mmathis76) Date: 2006-08-01 11: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-30 04: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 15: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 16: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 |
|
From: SourceForge.net <no...@so...> - 2006-08-01 01:17:43
|
Bugs item #1115849, was opened at 2005-02-03 16:50 Message generated for change (Comment added) made by scooper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1115849&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: dbunit Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Stephen Cooper (scooper) Assigned to: Jeff Jensen (jeffjensen) Summary: [dbunit] Set autocommit to true Initial Comment: Not all JDBC drivers have autocommit = true as the default. DBUnit seems to require this. I'll be posting a similar bug to dbunit, but for now the most expedient solution for my problem is to patch maven-dbunit-plugin. Here's the diff: cvs diff src/main/net/sourceforge/mavenplugins/dbunit/DbUnitTool.java Index: src/main/net/sourceforge/mavenplugins/dbunit/DbUnitTool.java =================================================================== RCS file: /cvsroot/maven-plugins/maven-plugins/dbunit/src/main/net/sourceforge/mavenplugins/dbunit/DbUnitTool.java,v retrieving revision 1.3 diff -r1.3 DbUnitTool.java 152a153 > jdbcConnection.setAutoCommit(true); 218c219 < } \ No newline at end of file --- > } ---------------------------------------------------------------------- >Comment By: Stephen Cooper (scooper) Date: 2006-07-31 19:17 Message: Logged In: YES user_id=452072 I stopped using maven and dbunit back in November. I won't be able to test this. Close it if you feel it works. ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-07-30 15:32 Message: Logged In: YES user_id=498804 Thanks for reporting this (a long time ago! :-(. I have committed your change and published 1.8-snapshot. Please test and report your results here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1115849&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-07-31 17:39:07
|
Bugs item #1515768, was opened at 2006-07-02 03:14 Message generated for change (Comment added) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1515768&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: webtest Group: None Status: Pending Resolution: None Priority: 9 Submitted By: Krystian Nowak (krystian_nowak) Assigned to: Siegfried GOESCHL (wdsgoe) Summary: [webtest] needs 2.0 to work with dojo Initial Comment: Since webtest plugin in version 1.2 doesn't work with applications using dojo (http://dojotoolkit.org/) I had to upgrade dependencies in the plugin to canoo webtest 2.0 which works with dojo. Home-made version (1.3-RC-1) of the plugin is waiting to be reviewed by webtest plugin developers, but I couldn't attached it - I guess due to the file size. How can I do it? Kind regards, Krystian Nowak ---------------------------------------------------------------------- >Comment By: Jeff Jensen (jeffjensen) Date: 2006-07-31 12:38 Message: Logged In: YES user_id=498804 Hi Siegfried! Thank you very much for following up with this... Yes, please apply the changes to the plugin's CVS! The patches referred to in this thread are not anywhere at SF, attached to any tracker items that I have found. I do not think the source has changed here in at least 9 months, so your changes should merge nicely from where you started from. Also, there is outstanding bug # 861603 that you had posted a comment to, mentioning fixing it. Would you mind updating it, possibly closing it if it is done?? Would be great to get all this set for your release on Wed! :-) Just ask if I can help you with anything. ---------------------------------------------------------------------- Comment By: Siegfried GOESCHL (wdsgoe) Date: 2006-07-31 01:51 Message: Logged In: YES user_id=183881 Hi folks, since I'm out of the maven-plugins loop ... +) I created a local version of the Maven Canoo WebTest plugin which is a bad thing to start with ... :-( +) Are the patches you are talking about already under CVS - if yes then I only have to merge my changes with the CVS head revision +) I will release the plugin on Wednesday ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-07-29 22:04 Message: Logged In: YES user_id=498804 Thanks, I appreciate you tracking that down! I do not use the plugin, so will rely on your/actual users help to ensure it works correctly to your satisfaction. ---------------------------------------------------------------------- Comment By: Krystian Nowak (krystian_nowak) Date: 2006-07-29 14:09 Message: Logged In: YES user_id=1294218 Right now I guess only Siegfried Goeschl can generate diff files, since my fix was totally unaware of changes in current version of the plugin. Siegfried has it and I hope he can help you. I will try to notify him about it. Regards, Krystian ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-07-29 14:03 Message: Logged In: YES user_id=498804 Would still like the diffs or the entire changed files to apply, if you will provide only the changed files. ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-07-27 09:51 Message: Logged In: YES user_id=498804 If someone wants it applied to the source here, attach patch(es) and I will gladly apply and release snapshots until we get it to work. ---------------------------------------------------------------------- Comment By: Krystian Nowak (krystian_nowak) Date: 2006-07-27 09:05 Message: Logged In: YES user_id=1294218 It's already done here http://people.apache.org/~sgoeschl/ by Siegfried Goeschl ---------------------------------------------------------------------- Comment By: Jeff Jensen (jeffjensen) Date: 2006-07-26 22:47 Message: Logged In: YES user_id=498804 Don't attach entire plugin, attach only patches of changed files. Are the only changes the POM dependencies? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=1515768&group_id=61626 |
|
From: SourceForge.net <no...@so...> - 2006-07-31 17:34:56
|
Bugs item #861603, was opened at 2003-12-17 06:11 Message generated for change (Settings changed) made by jeffjensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=861603&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: webtest Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Siegfried GOESCHL (wdsgoe) >Summary: [webtest] fails when maven.webtest.ant.options is not set Initial Comment: my setup: maven-rc2-SNAPSHOT java 1.4.2 debian linux (unstable) webtest-plugin 0.8.1 I always got this error when I tried to execute my tests: <snip> [java] [java] BUILD FAILED [java] Target `' does not exist in this project. [java] <snip> After looking at the jelly-scripts of the webtest-plugin, I tried setting the maven.webtest.ant.options property (to -v) and it worked. Edmund em...@li... ---------------------------------------------------------------------- Comment By: Siegfried GOESCHL (wdsgoe) Date: 2005-01-10 03:27 Message: Logged In: YES user_id=183881 I reintroduced this bug and will fix it again in the next release of the webtest plugin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=497853&aid=861603&group_id=61626 |
