I'm having a gradle script to execute Kotlin code with the gradle application plugin:
plugins {
id 'org.jetbrains.kotlin.jvm' version '1.4.10'
id 'application'
}
repositories {
mavenCentral()
}
dependencies {
implementation platform("org.jetbrains.kotlin:kotlin-bom")
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
// Some other deps
}
sourceSets {
main.kotlin.srcDirs += '.'
}
application {
mainClassName = 'MainKt'
}
What I would like to achieve: During the docker container startup I would like to load all the necessary dependencies with gradle build --build-cache command and be able to run gradle run --offline in the offline mode when the image is ready.
What do I have at the moment: I'm getting No cached version of org.jetbrains.kotlin:kotlin-scripting-compiler-embeddable:1.4.10 available for offline mode. error because plugin dependencies are not being cached during the build phase.
Any ideas what I can do to force gradle to cache not only listed dependencies but also dependencies required by plugins?
Adding the plugin dependency to the dependency list explicitly helped me to resolve this issue:
dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
implementation "org.jetbrains.kotlin:kotlin-scripting-compiler-embeddable" // <-- this solves the problem
// Some other deps
}
I hope this answer will be helpful! Although the use-case is pretty narrow.
Related
I have a simple spring boot project using the kotlin gradle dsl. I want to generate an OpenApi client using the openapi client generator gradle Plugin. I have successfully done so, using this configuration. Until now, this was a single project build. But when i try to include it, i get an error message "Could not find method wrapper()".
This is how i generated the client and added it's file into my source sets:
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
plugins {
id("org.springframework.boot") version "3.0.2"
id("io.spring.dependency-management") version "1.1.0"
kotlin("jvm") version "1.7.22"
kotlin("plugin.spring") version "1.7.22"
id("org.openapi.generator") version "6.3.0"
}
// other dependencies
openApiGenerate {
generatorName.set("kotlin")
inputSpec.set("src/main/openapi/my-api.yml")
outputDir.set("$buildDir/generated/my-api")
packageName.set("com.myapi")
}
kotlin.sourceSets["main"].kotlin.srcDir("$buildDir/generated/my-api/src/main/kotlin")
Now i want to use this generated client in my project. It comes with it's own build.gradle (in groovy) which loads the necessary dependencies etc.
I have modified my settings.gradle.kts file accordingly:
rootProject.name = "myapp"
include("build:generated:my-api")
When i reload gradle, i get the follwing error:
> Could not find method wrapper() for arguments [build_gdswinwcvulw9afq79kj4v6h$_run_closure1#582f32f7] on project ':build:generated:my-api' of type org.gradle.api.Project.
This is due to the build.gradle file generated by the generator looking like this:
group 'org.openapitools'
version '1.0.0'
wrapper {
gradleVersion = '7.5'
distributionUrl = "https://services.gradle.org/distributions/gradle-$gradleVersion-all.zip"
}
buildscript {
ext.kotlin_version = '1.7.21'
repositories {
maven { url "https://repo1.maven.org/maven2" }
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
}
}
apply plugin: 'kotlin'
apply plugin: 'maven-publish'
repositories {
maven { url "https://repo1.maven.org/maven2" }
}
test {
useJUnitPlatform()
}
dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
implementation "org.jetbrains.kotlin:kotlin-reflect:$kotlin_version"
implementation "com.squareup.moshi:moshi-kotlin:1.13.0"
implementation "com.squareup.moshi:moshi-adapters:1.13.0"
implementation "com.squareup.okhttp3:okhttp:4.10.0"
testImplementation "io.kotlintest:kotlintest-runner-junit5:3.4.2"
}
I am using Gradle 7.6 and i am a bit out of ideas here since i am pretty new to Gradle.
I'd like to load my custom plugin from a local jar. The jar file compiles fine and when I check it, the manifest and the plugin class are there.
gradlePlugin {
plugins {
create("asdf") { // <-- I really call it "asdf" in the kts script
id = "asdf"
implementationClass = "pluginTest.TestPlugin"
version = "1.4.0"
}
}
}
The plugin doesn't do anything useful yet as it should be a proof-of-concept to make sure it actually works at all:
class TestPlugin : Plugin<Project> {
override fun apply(project: Project) {
println("Hallo TestPlugin!")
}
}
I then try to use it like this in another project:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath(files("..\\..\\path\\to\\pluginTest.jar"))
}
}
plugins {
id("asdf") version "1.4.0"
}
but it keeps telling me that:
Plugin [id: 'asdf', version: '1.4.0'] was not found in any of the following sources:
What am I missing here? I use Gradle v6.5.
When you have the plugin jar on the classpath, you can't have a version number in the plugin application. I guess this is because you can't have multiple jars with different versions on the classpath in the first place, so specifying a version here doesn't make any sense (except perhaps to validate that you are using the correct one). This won't fix the problem, but it is a start.
To be honest, I don't know why your approach still won't work. The buildscript block is supposed to set up dependencies for that particular script, and that should make the plugin visible to it. It doesn't for some reason.
Perhaps this is a bug or perhaps this is just an undocumented limitation on the use of the plugin {} block. Maybe you could ask over at the Gradle forums or create an issue for it. However, there are workarounds that don't involve publishing to a (local) Maven repository, which I agree can be a bit annoying.
If you use "apply from" instead of "plugins {}", it works. For some reason, the former can see the buildscript classpath whereas the latter can't:
// build.gradle (Groovy DSL)
buildscript {
dependencies {
classpath(files("..\\..\\path\\to\\pluginTest.jar"))
}
}
apply from: "asdf"
Alternatively, move the buildscript plugin from the build.gradle file to the settings.gradle file. This makes is available to the entire build classpath and will make it work with the plugin block:
// settings.gradle (Groovy DSL):
buildscript {
dependencies {
classpath(files("..\\..\\path\\to\\pluginTest.jar"))
}
}
// build.gradle (Groovy DSL)
plugins {
id("asdf")
}
Lastly, just in case you haven't considered it already, you may be able to add the plugin as a composite build. This will create a source dependency to the plugin and has the advantage that transitive dependencies will be carried over (the ones you put in the plugin's own dependency block) and that it will be built automatically if not up-to-date. I use this approach for integration testing my plugins and also sometimes to apply them to my other real projects to test them in a bigger setting before publishing new versions.
Do that with either:
// settings.gradle (Groovy DSL):
includeBuild("..\\..\\path\\to\\plugin")
// build.gradle (Groovy DSL):
plugins {
id("asdf")
}
Or without hard-coding it in the build (so you can dynamically switch between local and published versions):
// build.gradle (Groovy DSL):
plugins {
id("asdf") version "1.4.0" // Version is optional (will be ignored when the command line switch below)
}
// Run with:
./gradlew --include-build "..\\..\\path\\to\\plugin" build
With #BjørnVester's answer I figured it out!
You need to put the buildscript in settings.gradle.kts as it doesn't get executed in the build.gradle.kts even when placed before plugins.
buildscript {
repositories {
flatDir {
dirs("..\\reusable-kotlin\\build\\libs") // <-- folder with jars
}
}
dependencies {
classpath("com.hedev.kotlin:reusable-kotlin:1.4.0")
}
}
But there's a catch! You must use the file-name of the jar in the classpath's name identifier that goes like this:
group:file-name:version
The file gradle will look for will be file-name-version.jar or file-name.jar which you'll see in the error message if you make a mistake (I added the _ on purpose to trigger the error):
Could not resolve all artifacts for configuration 'classpath'.
Could not find com.hedev.kotlin:reusable-kotlin_:1.4.0. Searched in the following locations:
- file:/C:/some/path/reusable-kotlin/build/libs/reusable-kotlin_-1.4.0.jar
- file:/C:/some/path/reusable-kotlin/build/libs/reusable-kotlin_.jar
In order for this to work I also had to add the group property to the plugin itself:
gradlePlugin {
plugins {
create("asdf") {
id = "asdf"
implementationClass = "com.hedev.kotlin.gradle.TestPlugin"
version = "1.4.0"
group = "com.hedev.kotlin"
}
}
}
Finally you can apply it in build.gradle.kts with (no version here):
plugins {
id("asdf")
}
I’m building a Gradle Plugin with Kotlin, in one of the features I’m using Ktor and Coroutines. The plugin must to be included as classpath in third part projects.
Problem comes when I’m trying to use the Plugin in another project, I'm getting:
Caused by: java.lang.NoClassDefFoundError: kotlin/coroutines/Continuation on the consumer project.
I tried to isolate the Coroutines dependencies and apply transitive dependencies for Ktor but no success.
I have seen too different solutions(https://github.com/Kotlin/kotlinx.coroutines/issues/430) like applying ShadowJar to build a FatJar but maybe I’m missing something in the configuration. Once I apply the Shadow Plugin the jar is about 62Mb, even applying minimize size of the jar is 12MB.
The basic conf(based on the samples of Kotlin-DSL) of the plugin would be:
plugins {
`kotlin-dsl`
`maven-publish`
kotlin("jvm") version "1.3.10"
id("com.github.johnrengelman.shadow") version "4.0.3"
}
gradlePlugin {
plugins {
register("greet-plugin") {
id = "greet"
implementationClass = "GreetPlugin"
}
}
dependencies {
api("io.ktor:ktor-client-okhttp:1.0.1")
}
}
val sourcesJar by tasks.registering(Jar::class) {
classifier = "sources"
from(sourceSets.main.get().allSource)
}
val shadowJar: ShadowJar by tasks
shadowJar.apply {
baseName = "test"
classifier = ""
minimize()
}
The complete example is here:
https://github.com/cdsap/testPluginCoroutinesProblem
A more detailed error
java.lang.NoClassDefFoundError: kotlin/coroutines/Continuation
at io.ktor.client.engine.okhttp.OkHttp.create(OkHttp.kt:8)
at io.ktor.client.HttpClientKt.HttpClient(HttpClient.kt:36)
at io.ktor.client.HttpClientKt.HttpClient$default(HttpClient.kt:33)
at GreetPlugin.apply(GreetPlugin.kt:26)
at GreetPlugin.apply(GreetPlugin.kt:12)
I expect the plugin will build properly the coroutines dependency within Ktor and don't have big jar as dependency.
I have a Gradle Java project in which I'm using JSF with PrimeFaces.
In order to change it's theme, I added the required dependency in my build.gradle file, which most important parts are configured as follows:
apply plugin: 'war'
apply plugin: 'eclipse-wtp'
sourceCompatibility = 1.8
version = '1.0'
jar {
manifest {
attributes 'Implementation-Title': 'Arch Project',
'Implementation-Version': version
}
}
repositories {
mavenCentral()
jcenter()
maven { url 'https://repository.primefaces.org' }
maven { url 'https://repository.jboss.org/nexus/content/groups/public' }
}
configurations {
provided
}
sourceSets {
main.compileClasspath += configurations.provided
test.compileClasspath += configurations.provided
test.runtimeClasspath += configurations.provided
}
dependencies {
/* Cryptography API for BCrypt algorithm. */
compile 'de.svenkubiak:jBCrypt:0.4'
/* Primefaces. */
compile 'org.primefaces:primefaces:5.3'
/* Primefaces pepper grinder theme. */
compile 'org.primefaces.themes:pepper-grinder:1.0.10'
... another few dependencies
}
However, when I run gradle build on the console I get the following error:
C:\Users\bruno.gasparotto\git\archproject\archproject>gradle build
:compileJava
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all dependencies for configuration ':compile'.
> Could not resolve org.primefaces.themes:pepper-grinder:1.0.10.
Required by:
:archproject:1.0
> Could not HEAD 'https://repository.primefaces.org/org/primefaces/themes/pepper-grinder/1.0.10/pepper-grinder-1.0.10.pom'.
> peer not authenticated
What I've tried and didn't work so far:
Changed the dependency from pepper-grinder to all-themes.
Replaced https with http on PrimeFaces repo configuration in my build.gradle file.
Also, it's important to mention that:
The url https://repository.primefaces.org/org/primefaces/themes/pepper-grinder/1.0.10/pepper-grinder-1.0.10.pom is available if I try to access it through the browser.
I am NOT behind a proxy.
If I remove the pepper-grinder dependency, it works just fine.
The same setup used to work more than year ago, so I believe something new is happening.
Any ideas?
Thanks is advance.
I have a gradle project with a single module.
I have declared the 'provided' configuration to enable provided-scoped dependencies in the parent build.gradle file:
subprojects {
apply plugin: 'maven'
apply plugin: 'java'
apply plugin: 'idea'
configurations {
provided
}
idea {
module {
scopes.PROVIDED.plus += [configurations.provided]
}
}
sourceSets {
main.compileClasspath += configurations.provided
test.compileClasspath += configurations.provided
test.runtimeClasspath += configurations.provided
}
... other stuff...
}
In the module build.gradle I have declared the following dependencies:
dependencies {
testCompile 'org.elasticsearch:elasticsearch:2.3.1:tests'
compile 'org.apache.commons:commons-io:1.3.2'
compile 'org.apache.commons:commons-lang3:3.4'
compile 'org.elasticsearch:elasticsearch:2.3.1'
compile 'org.slf4j:slf4j-api:1.7.12'
provided 'org.slf4j:slf4j-simple:1.7.12'
}
When I expand the Gradle tool window, it declares the second to last dependency there as provided as well, even though it has compile scope:
I would expect to see the dependency listed with (Compile) next to it in this tool window, not (Provided).
So the question is: Why aren't I?
Is it because the implementation of slf4j (slf4j-simple) is provided, and depends on slf4j-api, so automatically makes that one provided as well? How do I stop that? Should I be stopping that? I want the API as a compiled dependency, but I want projects that use this to decide on their own implementation...
I had the very same problem with IntelliJ IDEA Ultimate build 163.12024.16. I wasn't able to fix it. BUT it magically disappeared when I upgraded to build 171.4249.39. (When using the previous build again, the scope goes back to the incorrect "provided" again.)