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:
Related
I have created a custom Kotlin compiler plugin for Gradle. It was inspired by kotlin-allopen (2) and sample-kotlin-compiler-plugin, and is supposed to make all Kotlin classes non-final.
The problem is, I'm unable to use it in my projects, I only get the following:
Caused by: org.gradle.api.plugins.UnknownPluginException: Plugin with id 'no.synth.kotlin.plugins.kotlin-really-allopen' not found.
at org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:131)
I have tried both the "new" plugin syntax:
plugins {
id "no.synth.kotlin.plugins.kotlin-really-allopen" version "0.1"
}
.. and the old one:
buildscript {
repositories {
mavenLocal()
}
dependencies {
classpath "no.synth.kotlin.plugins:kotlin-really-allopen:0.1"
}
}
apply plugin: "kotlin-really-allopen" // I've tried "no.synth.kotlin.plugins.kotlin-really-allopen" as well
So what am I doing wrong? Here's the plugin: https://github.com/henrik242/kotlin-really-allopen
EDIT: I have updated the repository with an example app and a README.md to easily reproduce the problem.
Your Gradle plugin doesn't seem to contain any entry under META-INF/gradle-plugins.
Gradle requires that every plugin ID is mapped to the implementation class, and this mapping is stored in META-INF/gradle-plugins resources.
To map the plugin ID kotlin-really-allopen, you would need a resource file
src/main/resources/META-INF/gradle-plugins/kotlin-really-allopen.properties.
See: Wiring for a custom plugin
You can also use the Gradle Plugin Development Plugin, which automatically generates these entries from the build script DSL.
Also, your repository doesn't seem to contain an actual Gradle plugin implementation, there's only the part that the compiler needs to load. For an example that contains the Gradle part too, take a look at kevinmost/debuglog.
Move apply plugin: "kotlin-really-allopen" in your build.gradle module app on top
I would like to use the incubating plugins block to build.gradle:
plugins {
id "com.jfrog.bintray" version "0.4.1"
}
By default, this pulls plugins from the Gradle plugin portal. However, we have a requirement in our organization that we need to use our internal Artifactory repository, rather than the public Gradle plugin portal or a similar repository.
I see that the pluginManagement block can be used to specify repositories, by adding the following to settings.gradle:
pluginManagement {
repositories {
maven {
url "https://artifactory.example.com/"
}
}
}
We have several repositories, along with some credential logic, so in the past, we have just had this all bundled in a script plugin at a remote URL, then accessed it in our build.gradle file like so:
apply from: "https://shared.example.com/repositories.gradle"
The repositories.gradle file currently contains a repositories {} block that has several repositories.
Is there any way that I can apply this remote script plugin to the pluginManagement block? I tried going into my settings.gradle file and doing it this way:
pluginManagement {
apply from: "https://shared.example.com/repositories.gradle"
}
However, I got the error message Could not find method repositories() for arguments. Is there some other way that I can get this to work?
Just because you apply the external Gradle script in a specific context (e.g. pluginManagement), it won't be executed in this context. The apply method is implemented by the Settings object, so it is chosen as target object by default. You can try to delegate the script to another object by using the to parameter in the map you pass to the apply method:
apply to: pluginManagement, from: "https://shared.example.com/repositories.gradle"
I have two projects (in a single git repository) that should have the same
repository {
}
section in their build.gradle.kts, but otherwise are completely unrelated.
Can I factor this common part out and include it in each respective build.gradle.kts? How?
Update In the 0.11.0 release, applyFrom(uri) was removed.
You should now instead use:
apply {
from("dir/myfile.gradle")
}
Old answer
With Groovy build scripts you can do something like apply from: 'dir/myfile.gradle' where dir/myfile.gradle is a file containing your shared repositories block.
In a similar fashion with Gradle Script Kotlin (at least with 0.4.1), you can use the applyFrom(script: Any) method.
build.gradle.kts
applyFrom("dir/myfile.gradle")
If you need to apply it from a subproject you could do something like:
applyFrom("${rootProject.rootDir}/dir/myfile.gradle")
No idea if it works with kotlin however you can try equivalent from plain gradle:
lol.gradle
apply plugin: 'java'
repositories {
mavenCentral()
}
build.gradle
apply from: 'lol.gradle'
Above works fine. Mind that lol.gradle has java plugin applied - it adds context where repositories is present hence can be applied.
We use an init script bundled in a custom gradle distribution to apply our corporate Nexus repository to every gradle project. It's worth considering if you have a lot of projects.
I encountered a similar problem when common config is replicated in each and every project. Solved it by a custom gradle distribution with the common settings defined in init script.
Created a gradle plugin for preparing such custom distributions - custom-gradle-dist. It works perfectly for my projects, e.g. a build.gradle for a library project looks like this (this is a complete file, all repository, plugin, common dependencies etc are defined in the custom init script):
dependencies {
compile 'org.springframework.kafka:spring-kafka'
}
I'm creating gradle custom plugin and one of my tasks needs to be sure that another plugin applied to same project. Because it will operate on top of it.
I want for users of my plugin to avoid setting up an explicit dependency to another plugin - I want to do it inside my plugin.
So, I want to have this plugin (https://plugins.gradle.org/plugin/org.hidetake.ssh) applied. It's my dependency.
The way how I create plugin - I just create a class code on groovy, put it in buildSrc\src\main\groovy and apply groovy plugin in project. So my custom plugin is visible to gradle on build phase. It works, I have few other plugins done this way for same project, so it's fine for now.
I've looked through other topics and google for same question, but I can not make this work for me. This how I apply the code:
void apply(Project project) {
project.buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "org.hidetake:gradle-ssh-plugin:1.1.3"
}
}
project.apply plugin: "org.hidetake.ssh"
...
The error message I got: Plugin with id 'org.hidetake.ssh' not found.
I tried to do it via gradle api also using project.repositories.mavenCentral() and project.dependencies.add and project.apply(plugin:'org.hidetake.ssh') then - doesn't work also - same error message. Tried to use long notation in project.dependencies.add("myConfig",[group:'org.hidetake', name:'gradle-ssh-plugin', version:'1.1.3']) - no result.
Appreciate if someone can guide to the correct syntax\way to make it work.
Ok, finally I got it. To solve the issue you need to do the following:
Place build.gradle in your buildSrc directory.
Declare dependency for the plugin as runtime. Like this:
repositories {
jcenter()
}
dependencies {
runtime 'org.hidetake:gradle-ssh-plugin:2.6.0'
}
Apply plugin explicitly in your own plugin definition. Like this:
void apply(Project project) {
project.pluginManager.apply('org.hidetake.ssh')
...
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.