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
Related
I am new to gradle and I am facing a weird problem while I’m trying to add a plugin in gradle. I know that we have to specify an if and version in plugin body for a gradle build, but I tried to add a plugin with some id and version. My question is..how does a gradle build know which artifact id to choose if there are multiple artifacts under same group id? I know that this might be a lame question...but I’m pretty new to gradle and I’d like to know your input.
Are you trying to apply the spring-boot-plugin?
If so, does the project you're trying to apply the plugin to have a buildscript block like this:
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:2.0.4.RELEASE"
}
}
apply plugin: "org.springframework.boot"
or a plugin closure:
plugins {
id "org.springframework.boot" version "2.0.4.RELEASE"
}
With a buildscript block, Gradle knows where to find the plugin because I've specified a repository for it to go look for it. After resolving the dependency path it finds and downloads the plugin, then puts it on the classpath for use in build.gradle files. It then only needs to get applied, i.e. apply plugin: ....
With the plugins closure, things are a bit trickier. Plugins are published under a unique id, which is looked up and gradle resolves the specified version. I'm not too terribly knowledgeable about how this is done, but here, new plugin mechanism , describes some differences between buildscript {} apply plugin: ... and plugins {}.
I have a java project to which I build it using gradle build and generate a war file.
Currently my requirement is to generate WSDL file at the time of build from java classes. I came to know about axis2-java2wsdl-maven-plugin and found the syntax of applying it in gradle. But I am not able to get the tasks list or the example of using this plugin in gradle to generate the WSDL file using this plugin.
Can anybody let me know of how to use this plugin or any other help so that I can generate WSDL file form my java classes.
Dependency section which I included in build.gradle:
repositories {
mavenCentral()
}
dependencies {
'org.apache.axis2:axis2-java2wsdl-maven-plugin:1.6.2'
}
axis2-java2wsdl-maven-plugin is a maven plugin not a gradle one.
Moreoever, gradle plugins must be defined in a buildscript closure or a plugins one if you want to use the new plugins DSL.
Here, you are just using the maven plugin as a regular dependency for your project.
As far as i know, there is not "java2wsdl" gradle plugin.
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')
...
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: