:warning: OLD EclEmma repository, new is located at https://github.com/eclipse/eclemma
License: Other
JaCoCo is a free Java code coverage library distributed under the Eclipse Public License.
I use eclipse 4.2.1, eclemma 2.2.0, jdk 1.7.0_09.
my error occurs when I use sqllite for very light data storage.
java.lang.instrument.IllegalClassFormatException: Error while instrumenting class org/sqlite/SQLite.
at org.jacoco.agent.rt_kqcpih.CoverageTransformer.transform(CoverageTransformer.java:91)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:186)
at org.sqlite.NestedDB._open(NestedDB.java:59)
at org.sqlite.DB.open(DB.java:77)
at org.sqlite.Conn.(Conn.java:88)
at org.sqlite.JDBC.connect(JDBC.java:64)
at java.sql.DriverManager.getConnection(DriverManager.java:579)
at java.sql.DriverManager.getConnection(DriverManager.java:243)
at com.zionex.t3schedule.enginebridge.auth.AuthenticationHandler$AuthenticationWorker.getPlannersInfo(AuthenticationHandler.java:638)
at com.zionex.t3schedule.enginebridge.auth.AuthenticationHandler.configureUserInformation(AuthenticationHandler.java:131)
at com.zionex.t3schedule.enginebridge.auth.AuthenticationHandler.initialize(AuthenticationHandler.java:120)
at com.zionex.t3schedule.enginebridge.controller.AuthenticationController.initialize(AuthenticationController.java:54)
at com.zionex.t3schedule.enginebridge.controller.EngineBridgeController.initialize(EngineBridgeController.java:67)
at com.zionex.t3schedule.enginebridge.controller.EngineBridgeController.initialize(EngineBridgeController.java:72)
at com.zionex.t3schedule.common.T3Schedule.initialize(T3Schedule.java:108)
at com.zionex.t3schedule.common.T3Schedule.main(T3Schedule.java:148)
Caused by: java.lang.RuntimeException: Class file too large!
at org.jacoco.agent.rt_kqcpih.asm.ClassWriter.toByteArray(Unknown Source)
at org.jacoco.agent.rt_kqcpih.core.instr.Instrumenter.instrument(Instrumenter.java:70)
at org.jacoco.agent.rt_kqcpih.core.instr.Instrumenter.instrument(Instrumenter.java:82)
at org.jacoco.agent.rt_kqcpih.CoverageTransformer.transform(CoverageTransformer.java:89)
......
The Lm class is invalid, exiting ...
you can get the sqlitejdbc-v054.jar from googling with filename(sqlitejdbc-v054.jar), (for example, sqlitejdbc-v054.jar)
How can I use eclemma for my environment?
Hi!
In our company we heavily use AspectJ for persistance aspects, which works like a charm.
Before introducing AspectJ to our toolchain, we were using EclEmma with good success - thank you were much for this good software :-)
But since we introducted AspectJ, there are many unit-tests that are not recognised as "covered" anmyore. That means they are still mentioned in the statistics and are marked all in red, like the code was never executed - but indeed it is. There is no real pattern in the affected classes (many abstract base classes are all red with 0% coverage, the more complex the more likely this problem occurs). There are small classes, that have this problem, but bigger ones seem to be more prone for this type of problem.
After reading in the forum etc.. it is clear that we are not the only ones with this problem. If I understand correctly, there is some type of class-byte-code-hashing to match the instrumented objects to the java classes. The reason for this is IIRC that there might be the same class in different versions (same full qualified name) but loaded from different classloaders, which makes them different. This might be the case in an OSGI setup, where each plugin features is own classloader?
But in our case (and in many of the others) it would suffice to use the full qualified name of the classes to do the matching. We don't use OSGI at all. The strategy for matching could be configurable (standard: hash-bases, FQN: full qualified name,as in my proposal).
Kind regards and keep up the good work - EclEmma worked awesome without AspectJ :-)
Benjamin Jung
New Option in Coverage view to modify the name and scope of existing sessions.
i am getting the following exception after execute my junit test.
After exception is thrown my application terminated without junit or console error and Junit view shows all test as passed.
Thanks
eclemma version: 2.2.0.201210261515
Session Data:
eclipse.buildId=M20120208-0800
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=tr_GB
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.java.product -consoleLog
Exception Track Trace:
java.lang.NullPointerException
at com.mountainminds.eclemma.internal.ui.coverageview.CoverageView$4.paint(CoverageView.java:188)
at org.eclipse.jface.viewers.OwnerDrawLabelProvider$OwnerDrawListener.handleEvent(OwnerDrawLabelProvider.java:59)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062)
at org.eclipse.swt.widgets.Tree.CDDS_ITEMPOSTPAINT(Tree.java:853)
at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:7375)
at org.eclipse.swt.widgets.Control.wmNotify(Control.java:5534)
at org.eclipse.swt.widgets.Composite.wmNotify(Composite.java:1896)
at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:5086)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4584)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985)
at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2425)
at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1533)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623)
at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:5937)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2531)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
For debugging JaCoCo integrations it would be useful to have an read-only class file editor to display JaCoCo analysis data:
brock_j
To help with debugging the result of instrumentations it might be a good idea to have a view or editor that can show the original bytecode and instrumented bytecode side by side.
I have implemented a prototype of this using the built in eclipse disassembler and compare viewers, but i think the result is a bit 'noisy' to be useful due to changes to program counters introduced by instrumenting. Will attach a screenshot to demonstrate
Additional session import wizard that retrieves execution data from a remote agent via TCP/IP connection.
In Eclipse I tried to run all JUnit tests for the src/test/java directory of a maven project. I get the error message "Error while analyzing package fragment root java at F//target/classes (code 5007).". The system could not find the file package-info.class.
The stacktrace is:
org.eclipse.core.runtime.CoreException: File not found: <project-root-dir>\target\classes\<package>\package-info.class.
at org.eclipse.core.internal.filesystem.Policy.error(Policy.java:55)
at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:371)
at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:797)
at org.eclipse.core.internal.resources.File.getContents(File.java:289)
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walkResource(ResourceTreeWalker.java:60)
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walkResource(ResourceTreeWalker.java:74)
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walkResource(ResourceTreeWalker.java:74)
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walkResource(ResourceTreeWalker.java:74)
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walkResource(ResourceTreeWalker.java:74)
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walkResource(ResourceTreeWalker.java:74)
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walkResource(ResourceTreeWalker.java:74)
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walk(ResourceTreeWalker.java:50)
at com.mountainminds.eclemma.internal.core.analysis.PackageFragementRootAnalyzer.analyzeInternal(PackageFragementRootAnalyzer.java:63)
at com.mountainminds.eclemma.internal.core.analysis.PackageFragementRootAnalyzer.analyze(PackageFragementRootAnalyzer.java:46)
at com.mountainminds.eclemma.internal.core.analysis.SessionAnalyzer.processPackageFragmentRoot(SessionAnalyzer.java:100)
at com.mountainminds.eclemma.internal.core.analysis.SessionAnalyzer.processSession(SessionAnalyzer.java:80)
at com.mountainminds.eclemma.internal.core.JavaCoverageLoader$LoadSessionJob.run(JavaCoverageLoader.java:81)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.io.FileNotFoundException: <project-root-dir>\target\classes\<package>\package-info.class (Das System kann die angegebene Datei nicht finden)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:362)
... 16 more
Seems like the ResourceTreeWalker should ignore package-info.
Original report can be seen here: http://code.google.com/p/powermock/issues/detail?id=402
Powermock guys asked us to report here as well.
What steps will reproduce the problem?
1.Create a powermock test with Mockito, the test class is decorated with @RunWith and @PrepareForTest annotation.
2.Run the Test with "coverage as".
What is the expected output? What do you see instead?
Expected: EclEmma shows correct code coverage report.
Instead: EclEmma shows zero code coverage on target class.
What version of the product are you using? On what operating system?
Please provide any additional information below.
N/A.
Add a Maven Mojo (could be called CheckMojo) that can stop the build if the Test Percentage Coverage (TPC) is below a given value, specified as a configuration in the project's pom.xml.
For example Clover does this:
<plugins>
<!-- Fail the build if the test coverage is below a given value. -->
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-clover2-plugin</artifactId>
<configuration>
<!-- Note that the overall TPC when including functional tests for this module is around 78% -->
<targetPercentage>${xwiki.clover.targetPercentage}%</targetPercentage>
</configuration>
<executions>
<execution>
<id>clover-check</id>
<phase>verify</phase>
<goals>
<goal>instrument-test</goal>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
That would help a lot...
I recently moved some projects to Java 7 (1.7.0_13) and subsequently get this error but only in isolated cases. It has taken some time to track down as it looked like it was a Proguard (4.8) issue, however it only occurs when running tests under Jacoco (0.6.2).
I have reduced the code to something small and replicable.
There are 2 maven projects, one is a "library" which just builds a JAR that is obfuscated using Proguard. The other project makes use of the JAR.
The library contains a class 'MyLib' which contains a private method init(long,Long) that the constructor calls. Proguard is set to obfuscate the internals, but keep the public class. Invoking that private method is where the error occurs.
The other project "test-app" uses the JAR that contains the obfuscated MyLib. It only contains a test class, where a test method instantiates the MyLib class.
If I don't run the test under Jacoco, no error is thrown.
If I remove the "dontoptimize" option to Proguard, no error is thrown - for this example only though. In my original project where this occurred first, it doesn't matter what I change in the proguard configuration. I always get the VerifyError when running tests that hit the equivalent private method.
If I change the init method so that it doesn't contain a long and a Long, then no error is thrown. Equally if I don't reference the Long inside the method, it all works.
To hit the problem, it is necessary to build "test-lib" under maven with the "install" target to get it into the local repo. Then either, build "test-app" under maven as well, or close the "test-lib" project in Eclipse and invoke the test class using the Jacoco runner in Eclipse. If the "test-lib" project is open in Eclipse when the unit test is invoked, then it obviously won't load the obfuscated class, and the test runs OK.
That's about as much as I can do at this stage.
This is my first post to github and I intended to add the ZIP of the 2 projects, but it appears that I can't do that. I could post the contents of the small source here, or email the ZIP to someone as per another ticket - I just didn't want to assume that that was OK.
I install EclEmma in eclipse and want to get coverage reports for an android project.
All android test cases extend AnroidTestcase, I can get Android Junit test from "Run as...", but no from "Coverage as...".
Does eclemma support it?
Trying to use the Install new Software and Marketplace to install. Both methods are reporting failures as shown below.
Consequently, it is not able to be installed. I am not able to see any previous versions.
The manual Install New Software option is reporting this with version 2.2.1.201306092145
Thanks..Andrew
An error occurred while collecting items to be installed
session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
Problems downloading artifact: osgi.bundle,org.jacoco.agent,0.6.3.201306030806.
MD5 hash is not as expected. Expected: 329d9ad61604ba7432fa0347ad9b92f1 and found 16ea11a91350738dd5ac1a73ed17d7e4.
Problems downloading artifact: osgi.bundle,org.jacoco.core,0.6.3.201306030806.
MD5 hash is not as expected. Expected: 2b3cb2e313b017dda475242c167577ba and found 3d53ad731a1c955a290f644d1e65b9e2.
Problems downloading artifact: osgi.bundle,org.jacoco.report,0.6.3.201306030806.
MD5 hash is not as expected. Expected: 0c3cf018b39303cb7160bd1c1ff855d4 and found 1080233d936c664ba1c3742242780b39.
marchof
For every highlighted line the tooltip should show:
brock_j
Just some random thoughts on this: If possible we don't want to pollute the existing annotation ruler as it will make it harder for the user to do basic things like setting breakpoints or navigating to super implementations. We also don't want to get in the way of the regular hovers within the text (javadoc and such)
We could possibly use an IPainter and LineBackgroundListener? to do the line coverage (green/yellow/red). If the colours are light enough it shouldn't distract the user too much, and they can be disabled if needed.
To support displaying the counters i think a new coverage ruler next to the existing annotation ruler would be the cleanest solution. There is less chance of it interrupting the users normal workflow.
Hello, since i use jacoco 0.6.1 and make mvn verify there is an exception:
java.lang.instrument.IllegalClassFormatException: Error while instrumenting class com/euroit/militaryshop/persistence/entity/UploadedMedia.
at org.jacoco.agent.rt_6l8m50.CoverageTransformer.transform(CoverageTransformer.java:91)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.datanucleus.JDOClassLoaderResolver.classOrNull(JDOClassLoaderResolver.java:553)
at org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:204)
at org.datanucleus.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:415)
at org.datanucleus.metadata.MetaDataManager.loadPersistenceUnit(MetaDataManager.java:767)
at org.datanucleus.jpa.EntityManagerFactoryImpl.initialisePMF(EntityManagerFactoryImpl.java:488)
at org.datanucleus.jpa.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:355)
at org.datanucleus.store.appengine.jpa.DatastoreEntityManagerFactory.<init>(DatastoreEntityManagerFactory.java:63)
at org.datanucleus.store.appengine.jpa.DatastorePersistenceProvider.createEntityManagerFactory(DatastorePersistenceProvider.java:35)
at javax.persistence.Persistence.createFactory(Persistence.java:172)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:112)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:66)
at com.euroit.militaryshop.persistence.EMF.<clinit>(EMF.java:10)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1004)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:957)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:490)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:461)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:353)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1029)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:925)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:490)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:461)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:607)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:106)
at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:57)
at org.springframework.test.context.support.AbstractDelegatingSmartContextLoader.delegateLoading(AbstractDelegatingSmartContextLoader.java:100)
at org.springframework.test.context.support.AbstractDelegatingSmartContextLoader.loadContext(AbstractDelegatingSmartContextLoader.java:248)
at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:124)
at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:148)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:313)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:284)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:88)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at org.jacoco.agent.rt_6l8m50.core.internal.instr.FrameTracker.pop(FrameTracker.java:602)
at org.jacoco.agent.rt_6l8m50.core.internal.instr.FrameTracker.visitVarInsn(FrameTracker.java:386)
at org.jacoco.agent.rt_6l8m50.asm.MethodVisitor.visitVarInsn(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.MethodVisitor.visitVarInsn(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.tree.VarInsnNode.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.tree.InsnList.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.tree.MethodNode.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.core.internal.flow.ClassProbesAdapter$1.visitEnd(ClassProbesAdapter.java:124)
at org.jacoco.agent.rt_6l8m50.asm.ClassReader.b(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.ClassReader.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.asm.ClassReader.accept(Unknown Source)
at org.jacoco.agent.rt_6l8m50.core.instr.Instrumenter.instrument(Instrumenter.java:69)
at org.jacoco.agent.rt_6l8m50.core.instr.Instrumenter.instrument(Instrumenter.java:82)
at org.jacoco.agent.rt_6l8m50.CoverageTransformer.transform(CoverageTransformer.java:89)
... 90 more
Noticed that the maven jacoco plugin appends the agent to the argLine property of the surefire plugin. Since I need to add some additional parameters to the jvm cmdline I ended up using something similar to this <argLine>-foobar ${argLine}</argLine> in order to preserve the jacoco agent. All works OK if I don't disable the jacoco plugin using the skip property. If I do that I end up with an argLine property which is not initialized and because of that the actual string "${argLine}" is appended to the jvm command line.
Is there a better way to handle extra surefire jvm arguments with the jacoco plugin?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.1</version>
<configuration>
<forkMode>once</forkMode>
<argLine>-foobar ${argLine}</argLine>
</configuration>
</plugin><plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<skip>${jacoco.skip}</skip>
</configuration>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<skip>${jacoco.skip}</skip>
</configuration>
</execution>
</executions>
</plugin>Many projects are runnig some of theirs parts in boot classapth for various reasons.
Right now jacoco is exuding boot classpath explicitly.
I think it is worthy to include possibility to cover also bootclassapth, however with strong documentation (as some parts, eg jacoco or java.lang must be excluded otherwise fatal error or endless loop occure )and especially with "use on your own risk" :)
For my own purposes I have added this behaviour to jacoco -
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20121127/ba8f6a1e/xboot-0001.patch (for reasons - http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-November/020984.html) .
This proof of concept is very simple, it s adding new agent switch xboot=true/false default si false, and let user to include/exclude what he needs. Then it is just not excluding the boot classapth.
I think this improvement can be fast-done one and will bring enormous benefits. From above proof-of-concept i can confirm it is working, as I have successfully covered several Xbootclassapth misusing projects.
Many projects are using eg Make or another commandline based toll as build framework and for launching of different testsuites.
It would be nice to have (except excellent API you have already now) direct commandline tool for merging of exec files and for report generating. I have write one by myself for this task - http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20121127/ba8f6a1e/jacoco-tool-0001.diff - ( from http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-November/020984.html) and I will be happy to help with inclusion of such a tool into your repository.
Thanx for this amazing tool,
J.
I wanted to test a class with the following code:
if (tree.getData.asInstanceOf[Boolean]) {
def expand(item: TreeItem): Unit = {
val parent_item = item.getParentItem
if (parent_item != null)
expand(parent_item)
item setExpanded true
}
tree_items.values.asScala foreach expand
}
I got an error message (see the image file).
If the expand function is converted to a private method, the test doesn't fail.
kate-sherwood@SF
I would like to make a feature request. I see a way to do code coverage of only the source that is in my Project Explorer (check the Source folders only checkbox in the preferences). I see a way to do code coverage of absolutely everything (uncheck the Source folders only checkbox). I'd like a third option: to check all the code for which there is source for -- but which might not be in my Project Explorer.
For example, I have JARs for various servers, including Tomcat, with .class files and .java files. If I check the "Source folders only" button, I don't get coverage of those servers' code. If I uncheck that button, I am A) blocked because a separate bug and B) it looks like it is trying to do code coverage on files which I don't have source for, e.g. com/sun/codemodel/JAnonymousClass
I don't care about the JAnonymousClass, but I would be interested in coverage for Tomcat.
I find code coverage most useful when a project can maintain 100% coverage. This gives a nice clear target. However, in practice there are usually code branches which are tricky to test where the best thing to do is to accept that the code branch will not get any coverage.
In a tool like Clover this can be formalised by using a ///CLOVER:OFF directive to turn off coverage for a block of code. It would be incredibly useful if Eclemma could support something similar.
I think this will be tricky because Eclemma processes bytecode which doesn't contain any code comments. Perhaps you could spot special method calls such as System.setProperty("eclemma", "off").
EclEmma is already pretty cool, but it'd be wonderful if it could do something similar to the equally marvellous NCrunch (www.ncrunch.net).
As a first pass, I'd like a mode whereby EclEmma runs every minute or so, so that the editor always shows coverage, and the package explorer shows the code coverage. In this mode, it would NOT update the junit viewer, in other words keeping out of the way of my own coding.
Later on, it could I suppose become more sophisticated and do automatic analysis of which tests to run based on edits (a la NCrunch). But I can imagine doing that would be quite a lot of work.
What I can say though is that I've paid good money on NCrunch and I would readily do the same if EclEmma had similar capabilities.
The error messages I get:
Message Box 1
Error while dumping coverage data (code 5013).
java.net.SocketException: socket closed
at java.net.DualStackPlainSocketImpl.accept0(Native Method)
at java.net.DualStackPlainSocketImpl.socketAccept(Unknown Source)
at java.net.AbstractPlainSocketImpl.accept(Unknown Source)
at java.net.PlainSocketImpl.accept(Unknown Source)
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at com.mountainminds.eclemma.internal.core.launching.AgentServer.run(AgentServer.java:108)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Session Data:
eclipse.buildId=M20130204-1200
java.version=1.7.0_17
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product
Message Box 2
No coverage data has been collected during this coverage session.
Please do not terminate the Java process manually from Eclipse.
Console shows:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at org.jacoco.agent.rt.internal_5d10cad.output.TcpClientOutput.createSocket(TcpClientOutput.java:85)
at org.jacoco.agent.rt.internal_5d10cad.output.TcpClientOutput.startup(TcpClientOutput.java:49)
at org.jacoco.agent.rt.internal_5d10cad.Agent.startup(Agent.java:126)
at org.jacoco.agent.rt.internal_5d10cad.Agent.getInstance(Agent.java:56)
at org.jacoco.agent.rt.internal_5d10cad.PreMain.premain(PreMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)
java.lang.NullPointerException
at org.jacoco.agent.rt.internal_5d10cad.output.TcpClientOutput.writeExecutionData(TcpClientOutput.java:72)
at org.jacoco.agent.rt.internal_5d10cad.Agent.shutdown(Agent.java:143)
at org.jacoco.agent.rt.internal_5d10cad.Agent$1.run(Agent.java:60)
Hello World
I tried with different versions of the plugin:
1.5.3: Works
2.0.0: Works
2.0.1: Works
2.1.0: Does not work
2.1.3: Does not work
2.1.4: Does not work
2.2.0: Does not work
Latest: Does not work.
I am using this on a development Windows Server 2008 R2 64 bit that uses a virtual loopback interface for specific processes and I am guessing that this is related.
The list of Java related processes currently is:
eclipse.exe
javaw.exe
java.exe
I'm trying to use JaCoCo to obtain the code coverage of the test runs of an Android application. I'm using offline instrumentation to obtain the coverage through a TCP connection, but until now my efforts have been unsuccessful.
Can you please tell me if the TCP server or client is supported in Android?
Thanks in advance.
There is no code coverage for those tests that verify whether an exception is thrown using @test(expected).
Such tests are colored in red meaning that have not been covered. This is confusing as those tests are actually executed and passed.
Running version 2.1.4.20120801111 against 3.7 Eclipse Indigo.
Support different between 2 session. This will help users to see different execution path between 2 sessions
Tried to get the coverage of a Java application started on my Windows system using Java Web Start.
Defined environment variable JAVAWS_VM_ARGS=-javaagent:D:\jacoco\lib\jacocoagent.jar=destfile=D:\jacoco\proptima_client.exec
"D:\jacoco\proptima_client.exec" file is created, but remains empty.
My system is: Windows XP 32-bit
My java console displays:
Java Web Start 1.6.0_30
Use version JRE 1.7.0_10-b18 Java HotSpot(TM) Client VM
Please help.
Thanks
Hi,
I found EclEmma not compatible with JDK7. After installing it in Eclipse, I was not able to launch it. However, I tried it in a different machine with JDK6 and it works perfect.
Thanks.
When the file package.class compiled from package.scala is encountered, an error message is displayed in a dialog.
Problem ocurred with Eclemma 2.2.0, Scala-IDE 2.9.2 under Eclipse 3.8.
In addition to the default preferences the agent options for
should be configurable on a per launch configuration base.
Does Jacoco supports coverage for integration tests run with soap ui plugin in maven because when I am trying to do it, it is giving 0% coverage.
When there is a need of 100% code coverage over tests there is always cases where this target can be met ...
For example we have a mandatory quality rule to always have a default case on a switch block but when default case is unreachable we can't have the 100% target.
Second example in defensive code a catch block whose exception can not be fired by unit test makes the code under the wanted 100%.
It would be interesting to have a way to filter known unreachable code from the analysis or from the report with a special comment block for example.
After upgrading to Mountain Lion (10.8) I'm unable to use EclEmma. This issue effects both Eclipse Indigo and Juno (4.2).
What happens is I launch e.g. a junit test and the junit view never updates with a count of unit tests or pass/fail. The process continues running, but there is no thread actually running any unit tests.
The unit tests work just fine outside of EclEmma.
Different runs of jacoco may result in slightly different coverage results (for example, see https://groups.google.com/d/topic/jacoco/8EpEUQRjr4s/discussion ).
It would be great that this doesn't fail the build. This could be easily achieved by adding a "tolerance" configuration parameter for the check mojo.
It would be used like this for example:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
...
<configuration>
<check>
<instructionRatio>70.68</instructionRatio>
<tolerance>10%</tolerance>
</check>}
</configuration>
</plugin>
In this case the build would fail only if the result is < 70.68% - 10%.
The update site is down. When you try to install EclEmma from the Eclipse workspace, it displays an error. When you attempt to manually add the site and discover software within it, same error.
User ash2k@SF reported, that the TestNG launch shortcut is broken.
I am writing a unit test that utilizes Hypersonic DB (HSQLDB) as a mock database. I am running on the latest Java 7 JDK (1.7.0_09), the latest Eclemma Eclipse plugin, and the latest HSQLDB version (2.2.9). When I run the unit test I get a hotspot JVM crash with the following information:
JRE version: 7.0_09-b05
Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode windows-amd64 compressed oops)
Problematic frame:
V [jvm.dll+0xf20b3]
If I run without eclemma, it works. If I run on Java 6, it works. It looks to be an issue with this specific combination of 3 technologies. Here is a simple unit test that encounters the issue:
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.Statement;
import org.junit.Test;
public class HsqldbAndEclemma {
@Test
public void yo() throws SQLException {
System.out.println("Before the hotspot");
Connection conn = DriverManager.getConnection("jdbc:hsqldb:mem:mydb", "sa", "sa");
System.out.println("Not printed out - hotspot error getting a connection");
String createTable = "CREATE TABLE DATA (ID INTEGER NOT NULL)";
Statement st = conn.createStatement();
st.execute(createTable);
conn.commit();
String query = "INSERT INTO DATA (ID) VALUES (?)";
final PreparedStatement s = conn.prepareStatement(query);
s.setInt(1, 1);
s.execute();
}
}
(you need to include the latest hsqldb-2.2.9.jar in the classpath.
I can provide an error report file (my Eclipse had an issue creating a core dump) if need be.
I have a massive project that will continue to run until you manually kill it (by pressing the little red square in eclipse to kill the program).
I want to be able to start it up, do some stuff, then kill it, and see what code was covered. But when I kill it, I get two prompts. One says:
"No coverage data has been collected during this coverage session. Please do not terminate the Java process manually from Eclipse."
The other says:
'com.mountainminds.eclemma.internal.core.launching.AgentServer' has encountered a problem. Error while dumping coverage data (code 5013)."
Is there a work-around to this? This tool would be AMAZING for my job if I could get it to work. Is there any way to see the coverage data after manually killing a java process? Can this be fixed to dump the coverage data that was captured?
Thank you
When using EclEmma with GWT (see https://developers.google.com/web-toolkit/doc/latest/DevGuideTestingCoverage) it is necessary to use a patched version of EclEmma. Reportedly "so that EMMA does not throw away the coverage data if the same class is loaded by different classloaders, as is common in GWT"
Needless to say, the GWT folks don't always keep themselves up to date with new releases of EclEmma.
It would be REALLY nice if this feature was pulled into EclEmma (ideally with a project-specific configuration option to allow the behavior to be turned on and off) so that we don't have to choose between keeping EclEmma up to date, or being able to use it with GWT.
This would likely help other people who are trying to do code coverage in situations in which non-standard class loading procedures are being employed.
If you set a coverage threshold that fails the build, the maven plugin will not fail the build if there's no tests since no coverage data file will be generated in this case.
This is obviously not correct... The build should fail in this case.
Thanks
Sometime open editors are do not get highlighted. Closing and opening the editor brings the highlighting back.
Transferred from SF: http://sourceforge.net/tracker/?func=detail&aid=1722680&group_id=177969&atid=883351
When using classes coming from jars that have been pack200'd, later reports (may them be provided by Ant or EclEmma) don't succeed to map the class found in jacoco.exec with classes part of the pack200'ed jars; and then report 0% coverage on those classes.
How to reproduce:
cd api; mvn verify will build a p2 update-sitecd client; mvn verify will consume a dependency from this p2 site and will run a testapi/org.jboss.tools.example.api into Eclipse (as a Maven project), import coverage session from client/target/jacoco.exec with EcliEmmacd api; mvn clean verify -Ppack200 will generate a p2 repo including pack200'ed jarcd client; mvn verify; will re-run test, but will resolve to the packed bundle instead of plain jarYou can make the same experiment with Ant, or Jenkins Jacoco plugin instead of EclEmma.
The content of the jacoco.exec file looks good, but something (class id?) is changed and prevent reports for matching source/class files with what's found in the jacoco.exec.
I am having a problem with a JUnit plugin test. Eclemma fails while calculating coverage stats.
I guess the problem is somehow related to #21
I synchronized the project with filesystem as it was advised, but alas, the result is the same.
Any advice please?
Thank you
eclipse.buildId=M20120914-1540
java.version=1.6.0_29
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_CH
Command-line arguments: -os win32 -ws win32 -arch x86_64
Error
Thu Jan 24 12:07:44 CET 2013
Error while analyzing package fragment root src at null (code 5007).
java.lang.NullPointerException
at com.mountainminds.eclemma.internal.core.analysis.ResourceTreeWalker.walk(ResourceTreeWalker.java:41)
at com.mountainminds.eclemma.internal.core.analysis.PackageFragementRootAnalyzer.analyzeInternal(PackageFragementRootAnalyzer.java:63)
at com.mountainminds.eclemma.internal.core.analysis.PackageFragementRootAnalyzer.analyze(PackageFragementRootAnalyzer.java:46)
at com.mountainminds.eclemma.internal.core.analysis.SessionAnalyzer.processPackageFragmentRoot(SessionAnalyzer.java:100)
at com.mountainminds.eclemma.internal.core.analysis.SessionAnalyzer.processSession(SessionAnalyzer.java:80)
at com.mountainminds.eclemma.internal.core.JavaCoverageLoader$LoadSessionJob.run(JavaCoverageLoader.java:81)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I'm currently using Clover for coverage, but I'm thinking about switching to jacoco. One of the nicer features of Clover is the display of test names (fq name) hitting a specific line of code.
I would very appreciate this feature in jacoco.
After upgrade eclipse to Juno and EclEmma to 2.1.4.201208011137, some of my tests went to fail with eclipse raising the following message errors:
1º - "No coverage data has been collected during this coverage session. Please do not terminate the Java process manually from Eclipse."
2º - "'com.mountainminds.eclemma.internal.core.launching.AgentServer' has encountered a problem. Error while dumping coverage data (code 5013). "
Details: "Error while dumping coverage data (code 5013). Connection reset"
I'm using JUnit with eclipse Juno, JDK(Oracle) 6 and the most recent EclEmma.
Only tests with the Spring TestContext Framework are failing.
When using the Groovy/Grails tool suite for Eclipse or GGTS, it would be nice to be able to run Coverags As -> Grails Command (test-app), so that coverage analysis would be run against the full suite of unit and integration tests.
When you have junit tests of the form:
@Test(expected=UnsupportedOperationException.class)
public void test_getProperty()
{
this.testThreadDeathRequest.getProperty("DontCare");
}
and you run coverage the test will not be marked as covered albeit the test has been executed.
java.lang.instrument.IllegalClassFormatException: Error while instrumenting class ru/open/haven/core/managers/impl/OrderManagerImplMethodAccess.
at org.jacoco.agent.rt_kqcpih.CoverageTransformer.transform(CoverageTransformer.java:91)
at sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.esotericsoftware.reflectasm.AccessClassLoader.defineClass(AccessClassLoader.java:25)
at com.esotericsoftware.reflectasm.MethodAccess.get(MethodAccess.java:197)
at ru.open.haven.dispatching.dispatcher.HandlerDescriptor.(HandlerDescriptor.java:23)
at ru.open.haven.dispatching.dispatcher.EventDispatcherImpl.init(EventDispatcherImpl.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:270)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:120)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedList(BeanDefinitionValueResolver.java:353)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:153)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedMap(BeanDefinitionValueResolver.java:378)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:161)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:270)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:120)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
at org.jbehave.core.steps.spring.SpringApplicationContextFactory.createApplicationContext(SpringApplicationContextFactory.java:72)
at org.jbehave.core.configuration.spring.SpringAnnotationBuilder.createApplicationContext(SpringAnnotationBuilder.java:105)
at org.jbehave.core.configuration.spring.SpringAnnotationBuilder.buildConfiguration(SpringAnnotationBuilder.java:47)
at org.jbehave.core.configuration.AnnotationBuilder.buildEmbedder(AnnotationBuilder.java:176)
at ru.open.haven.integration.tests.jbehave.HavenJBehaveJUnitRunner.(HavenJBehaveJUnitRunner.java:36)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.(JUnit4TestReference.java:33)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.(JUnit4TestClassReference.java:25)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 5140
at org.jacoco.agent.rt_kqcpih.asm.ClassReader.readLabel(Unknown Source)
at org.jacoco.agent.rt_kqcpih.asm.ClassReader.a(Unknown Source)
at org.jacoco.agent.rt_kqcpih.asm.ClassReader.accept(Unknown Source)
at org.jacoco.agent.rt_kqcpih.asm.ClassReader.accept(Unknown Source)
at org.jacoco.agent.rt_kqcpih.core.instr.Instrumenter.instrument(Instrumenter.java:69)
at org.jacoco.agent.rt_kqcpih.core.instr.Instrumenter.instrument(Instrumenter.java:82)
at org.jacoco.agent.rt_kqcpih.CoverageTransformer.transform(CoverageTransformer.java:89)
Eclipse v 4.2.0:
JDK 1.7.09
Windows 7 x64
Reflectasm 1.01, Jbehave 3.4, Junit 4.x, EclEmma 2.2.0.201210261515
Maybe its a bug on eclemma side. Please take a look at this bug at https://code.google.com/p/mockito/issues/detail?id=385&thanks=385&ts=1350291448
Sample code attached.
mickael.istria@SF
Since jacoco reports can easily be generated and published to a specific URL by a CI builds, it would be cool if developers would be able to "import" this URL and then having EclEmma polling this URL when necessary to get the latest release of a jacoco.exec files.
Example:
Fot JBoss Tools, we now have latest jacoco reports fille available at the following URL: https://hudson.jboss.org/hudson/view/JBossTools/view/JBossTools_Trunk/job/jbosstools-3.3_trunk.component--examples/lastSuccessfulBuild/artifact/sources/tests/target/jacoco.exec So we'd like the developers to give this URL to EclEmma and EclEmma will refresh it when necessary so that the developer will most often have lhe latest coverage results available without further effort in his workspace.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
