Jacoco JmockIt error with Gradle build -java.lang.UnsupportedOperationException - gradle

I am using jacoco gradle plugin. My Unit test cases are failing and getting below exception. I searched in form but didnt get answer. Same test cases are working fine with maven (jacoco-maven) plugin.
ava.lang.UnsupportedOperationException: class redefinition failed: attempted to change the schema (add/remove fields)
at sun.instrument.InstrumentationImpl.redefineClasses0(Native Method)
I am using jmockit 1.12 and jacoco toolVersion = '0.7.1.201405082137'

For me, the root cause is that I didn't put jmockit dependency before junit dependency. So please ensure you have dependencies like the following:
testCompile 'org.jmockit:jmockit:1.29'
testCompile 'junit:junit:4.12'

Both Jmockit and Jacoco instruments the class files. Jmockit does it first during the build process and when jacoco tries the same (later in the process) it says "oh oh, can't instrument an already instrumented class file". This issue happened with older versions of jacoco and jmockit. To see this error, enable --stacktrace option during Gradle build or --debug.
Now, using the latest jacoco and jmockit versions, we can solve this issue easily.
If you use jacoco (or use the latest one here):
toolVersion="0.7.1.201405082137"
or
toolVersion="0.7.2.201409121644"
or
toolVersion="0.7.5.201505241946"
See this: changes that went in 0.7.1 version.
For JMockit, you have to use jmockit version: 1.8 at least or later (1.9 to 1.13).
org.jmockit:jmockit:1.8
See this: changes that went under 1.8 version: http://jmockit.github.io/changes.html
I see the latest jmockit version out there is now 1.19, so use these two in Gradle with versions which are compatible and support each other.

Related

Trying to upgrade from Gradle 4.10 to 5.0, but am getting unresolved references errors

I'm trying to upgrade to Gradle 5, but am getting "Unresolved reference" errors when compiling - most of which are internal libraries that are within a classpath. Additionally, the javax.inject library somehow doesn't exist anymore.
I've tried individually adding in the libraries that are now missing, but it then fails to build for some reason (with some sort of abstract method error).
buildscript {
...
dependencies {
classpath "some-internal-classpath"
}
}
How do I get it so that Gradle 5 will be able to resolve those references from my internal classpath + have javax.inject again?
When upgrading to Gradle 5.x from Gradle 4.x, there is one change in behaviour that can cause what you observe:
Gradle 5.x will honour the compile / runtime separation of dependency declarations in POM files. This means that a transitive library that is in the runtime scope of Maven is no longer visible at compilation.
So the fix is usually to find out the libraries you were using in your code but did not depend upon explicitly.
A useful method for doing that investigation is to leverage the dependencies task of Gradle, focused on the compileClasspath, effectively running ./gradlew dependencies --configuration compileClasspath with Gradle 4.x and 5.x and analysing the differences.

publishing to mavenLocal using build.gradle.kts

I'm trying to publish an artifact to ~/.m2 (maven-local) and as a Gradle newbie, i'm not sure what i'm missing
All the examples i've seen so far suggests using a publishing block which throws deprecation warnings when i run any Gradle commands.
Also including the maven-publish plugin without any publishing block causes the same warnings.
repositories {
mavenLocal()
jcenter()
}
plugins {
`maven-publish`
kotlin("jvm") version("1.3.10")
id("org.jetbrains.dokka") version "0.9.16"
}
As part of making the publishing plugins stable, the 'deferred
configurable' behavior of the 'publishing {}' block has been
deprecated. In Gradle 5.0 the
'enableFeaturePreview('STABLE_PUBLISHING')' flag will be removed and
the new behavior will become the default. Please add
'enableFeaturePreview('STABLE_PUBLISHING')' to your settings file and
do a test run by publishing to a local repository. If all artifacts
are published as expected, there is nothing else to do. If the
published artifacts change unexpectedly, please see the migration
guide for more details:
https://docs.gradle.org/4.10.2/userguide/publishing_maven.html#publishing_maven:deferred_configuration.
If it actually published to maven-local, i might have ignored the warning for now, but it's not publishing at all, neither does gradle publishToMavenLocal, it simply says BUILD SUCCESSFUL in __s with the above warning.
Trying the recommended route (according to the link) of adding the publishing block inside a subprojects block causes lots of red in intellij
Not sure if that's Kotlin DSL or not ... trying something else that was shown on the Kotlin DSL version of the Gradle Docs:
Any idea what i'm missing?
Here's my Gradle version and other relevant info (IntelliJ has Kotlin 3.1.0)
gradle -version
------------------------------------------------------------
Gradle 4.10.2
------------------------------------------------------------
Build time: 2018-09-19 18:10:15 UTC
Revision: b4d8d5d170bb4ba516e88d7fe5647e2323d791dd
Kotlin DSL: 1.0-rc-6
Kotlin: 1.2.61
Groovy: 2.4.15
Ant: Apache Ant(TM) version 1.9.11 compiled on March 23 2018
JVM: 1.8.0_151 (Oracle Corporation 25.151-b12)
OS: Mac OS X 10.14.1 x86_64
I think all you need to do is apply the maven plugin then run the install task. Details of how to apply the plugin are here, e.g. using the Kotlin DSL you'd have:
plugins {
maven
}
Then you just run the install task, e.g. from your IDE (the Gradle window in IntelliJ in your case) or a command line, e.g. ./gradlew install.
Regarding applying the maven plugin, if you're new to Gradle you probably want to get clear on the Gradle plugins DSL (which the above code snippet is an example of). If you're not using that then the way you apply the plugin is slightly different (e.g. you have to use the apply command). There are details here. Note that the decision about whether to use the Gradle plugins DSL is different from the choice of using Groovy or Kotlin for the language in which you write the build.gradle file.

Use of the 'compileOnly' scope in Android projects?

I'm using Gradle 2.12 (or newer) with an appropriate version of the Android Gradle plugin in my project. Gradle 2.12 introduced the compileOnly configuration, so why do I get an error when I try to use it?
Could not find method compileOnly() for arguments
Note the following sentence from the Gradle 2.12 release notes regarding the new compileOnly configuration (my emphasis):
You can now declare dependencies to be used only at compile time in conjunction with the Java plugin.
So the Java Gradle plugin is a component we need to consider when answering this question. We can find the compileOnly configuration declared in the Java Gradle plugin source code for new enough versions.
However, the Android Gradle plugins do not direct extend the Java Gradle plugin. In fact, I believe the Android plugins represent a sort of 'frankenplugin', with some functionality borrowed but not inherited from the Java plugin. The following chunks of source code support this idea.
From the base Android plugin class:
project.apply plugin: JavaBasePlugin
The Android Gradle plugins therefore incorporate functionality from the base Java Gradle plugin, not from the full Java Gradle plugin. Moreover, there is an explicit check that the full Java Gradle plugin is not applied alongside an Android Gradle plugin:
// get current plugins and look for the default Java plugin.
if (project.plugins.hasPlugin(JavaPlugin.class)) {
throw new BadPluginException(
"The 'java' plugin has been applied, but it is not compatible with the Android plugins.")
}
Based on this information, my guess is that compileOnly has just not been manually ported from the Java Gradle plugin to the Android Gradle plugin yet. It probably won't appear before we get an Android Gradle plugin with minimum Gradle version set at 2.12 or higher.
Simple use provided instead of compileOnly
See https://github.com/google/auto/issues/324#issuecomment-212333044

How to apply a different version of a Gradle plugin?

I am trying to use a newer version of the JaCoCo plugin and running gradle dependencies shows me that it's running version 0.7.1.201405082137 when I would like to be running 0.7.5.201505241946.
Any idea how this can be done or if the plugin with the new version of JaCoCo is even available yet?
Thanks!
I figured it out. I just had to add
jacoco {
toolVersion = "0.7.5.201505241946"
}

Code coverage for EJB's Using Wildfly-Arquillian-Gradle-Jacoco

I am trying to set-up code coverage for my project. I am using Wildfly 8.2 server, gradle as a build tool, and JUnit and Arquillian for testing. In gradle I have configured jacoco plugin to generate code coverage. I have a task called jacocoTestReport which allows me to generate an html report.
Something about running the tests:
I am working on a multi module project, each sub-project has a Deployments class in which we have two methods - one for creating a shrinkwrap archive of REST classes and other for non-REST classes. In arqullian.xml we are configuring this as REST_CONTAINER and NON_REST_CONTAINER and giving path to WildFly installation directory. When we run gradle build test , It will run the whole tests by deploying the REST.ear and non-REST.ear and generate the coverage reports.
The issue is code coverage for EJB's and other server managed classes are showing 0% (From primary ananlysis of coverage report). Also I analysed the jacoco.exec, there I found the classes which are showing 0% coverage are not listed in the file (Mostly bean classes).
Can someone provide me the correct configuration which works for the combination: Wildfly-Arquillian-Gradle-Jacoco
Note: I am ok to use tools other than jacoco, tried cobertura but same result.
This worked for me (but I used jboss7 should not be a problem) source:https://developer.jboss.org/thread/241883
apply plugin: 'jacoco'
jacoco {
toolVersion = '0.7.4.201502262128'
reportsDir = file("$buildDir/jacoco")
}
dependencies {
testCompile 'YOUR_ARQUILLIAN_ADAPTER'
testCompile 'org.jboss.arquillian.junit:arquillian-junit-container:1.1.5.Final'
testCompile 'org.jboss.arquillian.extension:arquillian-jacoco:1.0.0.Alpha7'
}
// Important: add the Jacoco libs on the test classpath (required for the Jacoco Arquillian extension to work).
sourceSets {
test.runtimeClasspath += configurations.jacocoAnt
}

Resources