I have 2 modules in an intellij project..One intellij plugin module and another one is an gradle module.
I need to call a class of the plugin module from the gradle module..I did add dependency of module by following this path: Project structure->module->Module dependency.But it is not resolved.
I have also added the below code in:
settings.gradle
include ':Change',':module'
build.gradle
dependencies{
compile project (:Change)
}
Here 'Change' is the name of the intellij plugin module.
Every time I try to build the gradle it throws below error:
Could not determine the dependencies of task ':distTar'.
Could not resolve all task dependencies for configuration ':runtimeClasspath'.
> Could not resolve project :ChangeImpactAnalysis.
Required by:
project :
> Unable to find a matching configuration of project :ChangeImpactAnalysis: None of the consumable configurations have attributes.
Please help
I'm struggling with Gradle and the build configuration of the following project structure (pretty simple...):
/projA
/projB
/projC
projC using classes from projB.
In projA/settings.gradle:
include 'projB'
include 'projC'
In projC/build.gradle:
dependencies{
compile project(':projB')
}
In IntelliJ I have no problem of dependency resolution, but when I'm running a ./gradlew build in projA, I'm facing a compilation error:
ClassC: Unresolved reference: ClassB
(where ClassC is the class of projC which is failing on the use of ClassB which is a class from projB, obviously...)
Notice that the code is in Kotlin language, that I do not have any problem to run the app in IntelliJ (spring boot run), but any build with Gradle give me an error (both in Intellij and command line).
What am I missing?
Regards,
Adrien
It's a common Gradle idiom to have an additional top level directory for your rootProject. That's a special project that's the parent to all other projects in your build, in a multi-project build.
That's where your settings.gradle file goes:
include ':projA:projB'
include ':projA:projC'
Then, I'd recommend having projA as a subdirectory of your rootProject, so your hierarchy would look as follows:
/myProject
settings.gradle
/projA
build.gradle
/projB
build.gradle
/projC
build.gradle
Also, in projC/build.gradle, you'll want instead:
dependencies {
compile project(':projA:projB')
}
That should do it.
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 :)
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 very simple structure of project that uses Spring-boot. It is web application that uses some lib that uses jdbc.
So my root setting.gradle is following:
include ':app:myWeb', 'components:myBackend'
application's standalone build.gradle compiles reusable lib with:
...
compile(project(":components:myBackend"))
...
But during compilation of myBackend I can get 2 types of errors:
1) no main class (but remember it is a lib), so I can fix it by turning off apply plugin: 'spring-boot'
2) Or error is following:
Could not resolve all dependencies for configuration ':components:myBackend:compile'
Could not resolve org.springframework:spring-jdbc:. Required by:SBSServer.components:myBackend:unspecified
So my question is: how to create reusable library that uses spring-jdbc?
The text of myBackend build.gradle is there http://codepad.org/Xg3Kys73
Instead if removing the spring-boot plugin completely you probably just need to switch off the repackage task:
bootRepackage {
enabled = false
}