Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 207600 - Cobertura coverage broken with Java 7 language features
Cobertura coverage broken with Java 7 language features
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Maven
7.1
All All
: P3 (vote)
: 7.2
Assigned To: Jesse Glick
issues@projects
http://wiki.netbeans.org/MavenCodeCov...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-21 17:11 UTC by everflux
Modified: 2012-05-18 02:19 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Minimal test case (2.82 KB, application/zip)
2012-05-16 21:02 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description everflux 2012-01-21 17:11:21 UTC
Product Version = NetBeans IDE 7.1 (Build 201112071828)
Operating System = Linux version 3.0.0-15-generic running on amd64
Java; VM; Vendor = 1.7.0_02
Runtime = Java HotSpot(TM) 64-Bit Server VM 22.0-b10

When using Java 7 the code coverage report is broken in Netbeans 7.1. The console shows JVM errors like
Expecting a stackmap frame at branch target 111 in method xxx.init()V at offset 53
  testCheckJava7EaJvm(xxx): Expecting a stackmap frame at branch target 111 in method xxxx.init()V at offset 53
  testCheckContainer(xxxx): Expecting a stackmap frame at branch target 111 in method xxx.init()V at offset 53
....
Seems like the cobertura version used is broken with Java 7.
Comment 1 everflux 2012-05-11 18:51:07 UTC
It seems like there is no intention that the cobertura team fixes the Java 7 related issues.
This leads to completely broken reports (and possibly even builds when running in a CI environment).
A possible alternative is the jacoco plugin based on eclemma: http://www.eclemma.org/jacoco/trunk/doc/maven.html
Comment 2 Jesse Glick 2012-05-11 21:18:00 UTC
It sounds like you are talking about the Cobertura integration with Maven projects?

(In reply to comment #1)
> It seems like there is no intention that the cobertura team fixes the Java 7
> related issues.

Do you have an upstream bug reference?
Comment 3 everflux 2012-05-12 08:39:54 UTC
Yes, this bug refers to the maven code coverage integration. 

Upstream bugs:
http://sourceforge.net/tracker/?func=detail&aid=3408140&group_id=130558&atid=720015
http://sourceforge.net/tracker/?func=detail&aid=3525884&group_id=130558&atid=720015

As mentioned in one of the bug reports there are patches available for cobertura, but no official release yet.
Since the last release of cobertura was 2010, the jacoco maven plugin which seems to be actively developed is an alternative.

It would be really disappointing if no code coverage for Java 7 maven projects is available in Netbeans 7.2. As the real culprit is not Netbeans I wonder how this should be handled in a proper way.
Comment 4 Jesse Glick 2012-05-16 21:02:38 UTC
Created attachment 119549 [details]
Minimal test case

Demonstration of both Cobertura bugs: VerifyError "Expecting a stackmap frame at branch target ...", "JavaNCSS got an error while parsing the java file ..."
Comment 5 Jesse Glick 2012-05-16 21:31:49 UTC
JaCoCo support would normally be considered a "feature" but since Cobertura is clearly broken for JDK 7 this could be treated as a bug fix I think. It does not look too hard.
Comment 6 Jesse Glick 2012-05-16 23:57:40 UTC
core-main #14bdc13fd8a6
Comment 7 Jesse Glick 2012-05-17 00:09:09 UTC
Testing would be much appreciated, once this change appears in nightly development builds (an automated notation will be added to this issue when that happens).
Comment 8 everflux 2012-05-17 13:58:04 UTC
Could not wait for nightly build so I ran my own :)
Build 20120517-82ea49a7fe37 looks very promising, code coverage was finally working again with my beloved Netbeans. Thank you!

I noticed some IOExceptions on the console when Netbeans tried to add file watches.

[exec] WARNING [org.netbeans.modules.masterfs.watcher.Watcher]: Cannot add filesystem watch for /home/tkruse/... (a directory): java.io.IOException: addWatch on /home/tkruse/arbeit/... (same directory) errno: 2

In addition to that it may be the case that the parsing of the jacoco result is started too early?

    [exec] CONFIG [null]: Parse error in file file:/home/tkruse/arbeit/.../target/site/jacoco/jacoco.xml line 1 column 1,146,881 (PUBLIC null)
     [exec] INFO [org.netbeans.modules.maven.coverage.MavenCoverageProvider]: Could not parse home/tkruse/arbeit/.../target/site/jacoco/jacoco.xml
     [exec] org.xml.sax.SAXParseException; systemId: file:home/tkruse/arbeit/.../target/site/jacoco/jacoco.xml; lineNumber: 1; columnNumber: 1146881; XML document structures must start and end within the same entity.
     [exec] 	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)
     [exec] 	at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:441)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:368)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1375)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:864)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:564)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1353)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1774)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanLiteral(XMLEntityScanner.java:1074)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLScanner.scanAttributeValue(XMLScanner.java:774)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanAttribute(XMLDocumentFragmentScannerImpl.java:1506)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1279)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2715)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607)
     [exec] 	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488)
     [exec] 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835)
     [exec] 	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
     [exec] 	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
     [exec] 	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:237)
     [exec] 	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:300)
     [exec] 	at org.openide.xml.XMLUtil.parse(XMLUtil.java:356)
     [exec] [catch] at org.netbeans.modules.maven.coverage.MavenCoverageProvider.parse(MavenCoverageProvider.java:223)
     [exec] 	at org.netbeans.modules.maven.coverage.MavenCoverageProvider.getResults(MavenCoverageProvider.java:330)
     [exec] 	at org.netbeans.modules.gsf.codecoverage.CoverageManagerImpl.resultsUpdated(CoverageManagerImpl.java:255)
     [exec] 	at org.netbeans.modules.gsf.codecoverage.CoverageManagerImpl$1.run(CoverageManagerImpl.java:106)
     [exec] 	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
     [exec] 	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:701)
     [exec] 	at java.awt.EventQueue.access$000(EventQueue.java:102)
     [exec] 	at java.awt.EventQueue$3.run(EventQueue.java:662)
     [exec] 	at java.awt.EventQueue$3.run(EventQueue.java:660)
     [exec] 	at java.security.AccessController.doPrivileged(Native Method)
     [exec] 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
     [exec] 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:671)
     [exec] 	at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:158)
     [exec] 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:244)
     [exec] 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:163)
     [exec] 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
     [exec] 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:147)
     [exec] 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:139)
     [exec] 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)
     [exec] CONFIG [null]: Parse error in file file:/home/tkruse/arbeit/.../target/site/jacoco/jacoco.xml line 1 column 1,146,881 (PUBLIC null)



This may be unrelated to this fix and due to a snapshot build.

On the first run the following issues was encountered http://netbeans.org/bugzilla/show_bug.cgi?id=212641 but I was unable to reproduce it.

I am unsure whether I should change the state of this issue. After all the expected output (coverage report, highlighting of the source files with green and red) was as expected.
Comment 9 Quality Engineering 2012-05-17 15:40:20 UTC
Integrated into 'main-golden', will be available in build *201205170950* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/14bdc13fd8a6
User: Jesse Glick <jglick@netbeans.org>
Log: #207600: adding support for JaCoCo as an alternative to Cobertura which works with JDK 7.
Comment 10 Jesse Glick 2012-05-18 02:19:13 UTC
(In reply to comment #8)
> it may be the case that the parsing of the jacoco result is started too early?
> 
>     [exec] CONFIG [null]: Parse error in file
> file:/home/tkruse/arbeit/.../target/site/jacoco/jacoco.xml line 1 column
> 1,146,881 (PUBLIC null)
>      [exec] INFO [org.netbeans.modules.maven.coverage.MavenCoverageProvider]:
> Could not parse home/tkruse/arbeit/.../target/site/jacoco/jacoco.xml
>      [exec] org.xml.sax.SAXParseException; systemId:
> file:home/tkruse/arbeit/.../target/site/jacoco/jacoco.xml; lineNumber: 1;
> columnNumber: 1146881; XML document structures must start and end within the
> same entity.

Could be. The IDE listens to this file but there is no file locking to coordinate with the external Maven process.

> I am unsure whether I should change the state of this issue. After all the
> expected output (coverage report, highlighting of the source files with green
> and red) was as expected.

If you more or less consistently see stack traces on console which you think are related to JaCoCo support, best to file a fresh bug blocking this one, so it can be prioritized and possibly fixed on its own. Reopening this bug would be appropriate just if the feature does not seem to work at all, but from your comments it seems it is basically functional.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo