I have configured my Gradle build script to make use of checkstyle together with the added sventu checkstyle checks, however when I execute the checkstyleMain task, the build fails with the following error:
* What went wrong:
Execution failed for task ':checkstyleMain'.
> Unable to create a Checker: cannot initialize module TreeWalker - Unable to instantiate AvoidConstantAsFirstOperandInConditionCheck
This happens even though I have included the checkstyle jar in my build. Below is the relevant parts of my build script:
repositories {
mavenCentral()
maven {
url "http://sevntu-checkstyle.github.com/sevntu.checkstyle/maven2"
}
}
checkstyle {
configFile = new File("etc/config/dev.xml");
toolVersion = "6.8"
}
configurations {
checkstyle
}
dependencies {
checkstyle "com.github.sevntu.checkstyle:sevntu-checks:1.13.4"
}
Note that the build works when I remove the dependencies section and test with a checkstyle xml doc that does not have the extra sevntu checks configured. My configuration is also similar to the example at sevntu-checkstyle/checkstyle-samples
What am I missing here?
So I finally figured it out:
Turns out the example at https://github.com/sevntu-checkstyle/checkstyle-samples/blob/master/gradle-project/build.gradle only works if you put the full classpath of the custom checks as the name for each custom check.
This is due to checkstyle not knowing where the custom checks are located in the package. Turns out checkstyle can find this out if you include a checkstyle_packages.xml file in the jar that describes the packages that contains the checks.
Unfortunately there is no such file in com.github.sevntu.checkstyle:sevntu-checks:1.13.4. To get this information, you also need to include "com.github.sevntu.checkstyle:sevntu-checkstyle-maven-plugin:1.13.4", which basically contains nothing but the checkstyle_packages.xml file.
So I've added this to my dependencies and the checkstyle rules finally parses:
dependencies {
checkstyle "com.github.sevntu.checkstyle:sevntu-checks:1.13.4",
"com.github.sevntu.checkstyle:sevntu-checkstyle-maven-plugin:1.13.4"
}
Hoping this will save someone some pain in future :)
Related
Is it possible to make one custom plugin in Grails 3 dependent on another custom plugin? Here's my project structure:
grails3-home
myApp
customPlugin1
build.gradle
settings.gradle
customPlugin2 ...
I would like to make customPlugin1 dependent on customPlugin2. Everything I've read says this possible with multi-project builds between apps and plugins in Grails 3. And I'm able to declare both plugins as dependencies in myApp with no issues. However, I have not been successful in getting this to work between the two plugins.
I have added the following line to customPlugin1 > settings.gradle
include "customPlugin2"
And to customPlugin1 > build.gradle
grails {
plugins {
compile project(':customPlugin2')
}
}
However when I try to build customPlugin1, I get the following error:
FAILURE: Build failed with an exception.
What went wrong:
A problem occurred configuring root project 'customPlugin1'.
Could not resolve all dependencies for configuration ':runtime'.
Project : declares a dependency from configuration 'compile' to configuration 'default' which is not declared in the descriptor for project :customPlugin2.
Is anyone aware if what I'm trying to do is possible, and if so, what I might be missing?
Update:
If I change my configuration to
include "../customPlugin2"
and
grails {
plugins {
compile project(':../customPlugin2')
}
}
the plugin builds successfully, but I am no longer able to import domains classes from customPlugin2 into customPlugin1 domains classes
You should do the include in the root settings.gradle
include 'myApp', 'customPlugin1', 'customPlugin2'
Then in plugin 1:
grails {
plugins {
compile project(':customPlugin2')
}
}
Note that this simply defines a dependency. If you need plugin 2 to load before or after plugin 1 you need to define that as well in the plugin descriptor.
I am building a SonarQube 6.2 server which is already analyzing my Java 8/Gradle 3.3 projects. When adding JaCoCo to a multimodule gradle project, I realized that SonarQube is measuring code coverage on a "per-module" basis:
If a class is located in module A and a test for this class is located in module B, SonarQube figures the class is not covered.
I want to measure code coverage across all modules, not on a per module basis. How do I achieve this?
There are lots of similar questions but no helpful answers, although the situation seems quite common to me. Jenkins for example does that per default.
I decided to build a blueprint on github to clarify the issue.
The main build.gradle consists of
plugins { id "org.sonarqube" version "2.2.1" }
subprojects {
apply plugin: 'java'
apply plugin: 'jacoco'
repositories { mavenCentral() }
dependencies { testCompile "junit:junit:4.12" }
}
modA/build.gradleis empty.
It contains 3 classes: TestedInModA, TestedInModATest and TestedViaModB.
modB/build.gradlejust declares a dependency to modA:
dependencies { compile project(':modA') }
It contains just one class: TestedViaModBTest, testing the class TestedViaModB located in modA.
My (private) Jenkins instance shows 100% coverage for the two classes included while SonarQube says only the class TestedInModA (which is tested in its own module) is covered.
How can I modify my build process to see "cross-module coverage" in SonarQube?
I would love to update my project so future visitors to this question can find a working example.
My working solution (thanks #Godin)
add the following to the subprojects closure
tasks.withType(Test) {
// redirect all coverage data to one file
// ... needs cleaning the data prior to the build to avoid accumulating coverage data of different runs.
// see `task cleanJacoco`
jacoco {
destinationFile = file("$rootProject.buildDir/jacoco/test.exec")
}
}
add
task cleanJacoco(dependsOn: 'clean') { delete "$buildDir/jacoco" }
outside the subprojects closure.
When you perform build JaCoCo Gradle Plugin will produce modA/build/jacoco/test.exec and modB/build/jacoco/test.exe that contain information about execution of tests in modA and modB respectively. SonarQube performs analysis of modules separately, so during analysis of modA for the file TestedViaModB it sees only modA/build/jacoco/test.exec.
Most common trick to cross boundaries - is to collect all coverage information into single location. This can be done with
JaCoCo Gralde Plugin
either by changing location - see destinationFile and destPath ( since information is appended to exec file, don't forget to remove this single location prior to build, otherwise it will be accumulating information from different builds and not just from different modules ),
either by merging all files into single one - see JacocoMerge task. And then specify this single location to SonarQube as sonar.jacoco.reportPath.
Another trick: SonarQube 6.2 with Java Plugin 4.4 supports property sonar.jacoco.reportPaths allowing to specify multiple locations.
If you are interested in the solution with sonar.jacoco.reportPaths (see answer of Godin), have looke at this gradle code:
tasks.getByName('sonarqube') {
doFirst {
// lazy initialize the property to collect all coverage files
def jacocoFilesFromSubprojects = subprojects.findAll {it.plugins.hasPlugin('jacoco')}
.collect {it.tasks.withType(Test)}.flatten().collect {it.jacoco.destinationFile}
sonarqube.properties {
property "sonar.jacoco.reportPaths", jacocoFilesFromSubprojects.join(',')
}
}
}
This will collect all coverage binary files and set them as comma-separated list to the sonar property. Considers all test tasks of sub projects where jacoco is applied and their jacoco destination file configured.
I have a jar that I need to include in my dependencies...
compile files('WebContent/WEB-INF/lib/wls-api.jar')
There's a class inside that jar that is causing trouble that I want to not be on the classpath when I run my app after a gradle build.
How do I get rid of that class after doing a gradle build?
it's a bit trickier than it looks like at first blink; because you will modify the original input!
You should create a configuration for the your modified artifact (this is a proof of concept build.gradle snipplet):
apply plugin: 'java'
task filteredJar(type:Jar){
// you may use a remote artifact by configuring a separate configuration for it and using a jar from:
// configurations.theConfig.resolvedConfiguration.resolvedArtifacts
from zipTree('a.jar')
archiveName 'xx.jar'
// use standard Copy/Sync like filters here, for the example i used
include '**/Tool.class'
}
configurations {
z1
}
artifacts {
z1 filteredJar
}
dependencies {
compile project(path: getPath(), configuration: 'z1')
}
or..alternatively, and might be more preferably:
put this magic into some separate project which will repackage this jar into a usebale one.
Here's the configuration to get the artifactory plugin:
buildscript {
repositories {
mavenCentral()
maven { url 'http://jcenter.bintray.com' }
}
dependencies {
classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
}
}
apply plugin:'com.jfrog.artifactory'
apply plugin:'ivy-publish'
...some publish spec stuff...
I run gradle (2.3) and I get:
> Failed to apply plugin [id 'com.jfrog.artifactory']
> Cannot cast object 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention#6b6c7be4' with class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention' to class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention'
Certainly looks like a classpath issue, but I literally have this project and a sibling project using this same set of gradle/artifactory configurations and one works and the other does not. Both are part of the same top level project. Same JDK (1.8.0_20). Same Gradle. Same everything.
I'm baffled...
The problem was that when I added the various bits to the sibling project that meant I had two projects defining the buildscript {} section.
buildscript {
...
dependencies {
classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
}
}
Apparently that caused two different versions of the dependency to exist in the classpath, hence the error.
The solution was to move the buildscript bit into the master project so those dependencies are only defined once:
buildscript {
repositories {
maven { url "https://plugins.gradle.org/m2/" }
}
dependencies {
classpath group:'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '3.0.1'
}
}
Here's another potential cause. All of this looks to be a problem with rival classloaders defining the class. The full qualified classes include the loader. so, load A foo.bar is not loader B foo.bar and crossing that divide is a complex dance requiring interfaces and careful definition.
So, when using the Jenkins artifactory plugin to build your gradle project with the gradle artifactory plugin, you must add the usesPlugin or jenkins plugin will generate an init script which adds the gradle plugin on to a class loader.
def server = Artifactory.server "artifactory"
def rtGradle = Artifactory.newGradleBuild()
rtGradle.usesPlugin = true // Artifactory plugin already defined in build script
...
My problem was, desktop build OK, jenkins build shows this post's problem
I was getting a similar exception when building with Jenkins. For me the conflict was with Jenkin's version and the version in the Build script:
To address this the Artifactory section of the build has a flag you can check specifying that you want to use the version from the gradle file:
This fixed my issue. Hope it helps.
I had a similar problem. Gradle seems to try to reach across and do some checking or evaluation across siblings. I have a top level settings.gradle with 10 or so subprojects.
The fix for me was to put the buildscript block and dependencies at the top level build.gradle and put it in each of the individual subprojects build.gradle files where needed.
My guess as to the reason this works is that the plugin gets loaded in the parent which will be a parent classloader, then each child project inherits that classloader such that the declaration in the lower child script uses that classloaders class and CCE does not occur. The problem is they are the same class, but not assignable since the different classloaders per subproject if nothing is declared at the top. This was Gradle 2.4, and using IntelliJ 14.
In case it helps someone, I got the same error, but for a different reason.
I had the following in my build.gradle:
dependencies {
classpath "org.jfrog.buildinfo:build-info-extractor-gradle:+"
}
At some point the artifactory plugin updated itself from version 3.x to version 4.x while building, because no specific version was specified for the dependency. After it updated I got the error (Could not find any convention object of type ArtifactoryPluginConvention).
I guess the problem was that the rest of the configuration in my build script doesn't work with the new plugin version. Setting the dependency to use version 3.x fixed the problem for me:
dependencies {
classpath "org.jfrog.buildinfo:build-info-extractor-gradle:3.+"
}
While the currently accepted answer correctly identifies the cause of this issue, the proposed solution doesn't work when you still need to be able to build individual subprojects (because then of course they no longer have access to the buildscript defined repositories and dependencies). The solution that worked for me was to have identical buildscript blocks in each of my subprojects, that seemed to be the key. Any variations would cause the original error.
I got the same exception thrown by bamboo:
'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention#18eb2827' with class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention' to class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention'
Since the bamboo Bamboo Artifactory Plugin by default looks for the gradle.propeties file in each sub-project module, it has to be provided there.
There is no need for publishing logic in the build.gradle file since the Bamboo Artifactory plugin will read the gradle.properties file for each module respectively, containing:
group=com.example
artifactId=your-project
version=1.0.0
The reason that I got the ArtifactoryPluginConvention exception thrown was that my configured build plan on Bamboo was misconfigured.
With misconfigured, the build ordered of the tasks was not correct. Have a look at your bamboo building tasks/preferably clone a Bamboo plan that is already working.
I have a few Gradle scripts that get applied via apply from: 'my-build.gradle'. If I use the new plugins DSL as follows in the external build file my-build.gradle, it fails with the following error:
> startup failed:
Only Project build scripts can contain plugins {} blocks
See http://gradle.org/docs/2.3/userguide/plugins.html#sec:plugins_block
for information on the plugins {} block
Looking at the documentation pointed in the error message didn't reveal as to why the restriction is in place. Why is there a restriction on the location of the plugins declaration?
Files for reference below.
my-build.gradle file:
plugins {
id "net.saliman.cobertura" version "2.2.5"
}
build.gradle file:
apply from: "my-build.gradle"
// Other stuff
This is how you can use plugins in external Gradle files such as your my-build.gradle:
buildscript {
repositories {
mavenCentral()
maven { url "https://plugins.gradle.org/m2/" }
}
dependencies {
classpath "org.sonarqube.gradle:gradle-sonarqube-plugin:1.1"
classpath "net.saliman:gradle-cobertura-plugin:2.2.8"
}
}
// Because this is a helper script that's sourced in from a build.gradle, we can't use the ID of external plugins
// We either use the full class name of the plugin without quotes or an init script: http://www.gradle.org/docs/current/userguide/init_scripts.html
apply plugin: org.sonarqube.gradle.SonarQubePlugin
apply plugin: net.saliman.gradle.plugin.cobertura.CoberturaPlugin
// rest of my-build.gradle omitted
Above I've activated the plugins for SonarQube and Cobertura.
Generally, to get the fully qualified class name of your plugin you will have to look inside its .jar file.
As for the technical reasons why you can't use a plugins {} block in an external file, I do not know. It might have to do something with the following:
[...] plugins [need to] be specified in a way that Gradle can easily
and quickly extract [them], before executing the rest of the build
script. It also requires that the definition of plugins to use be
somewhat static.
But rejoice:
Future versions of Gradle will remove this restriction.
I also faced similar issue recently and it got solved by changing Gradle settings in Intellij as follows: