My usecase is to copy files from another dependency and add it to the jar. For a build.gradle file it is done as
task copyConfiguration(type: Copy) {
from("${brazilGradle.path('[ABC]pkg.src')}")
into "${brazilGradle.buildDir}/schema"
}
sourceSets.main.resources {
srcDir "${brazilGradle.buildDir}/schema"
include 'src/*'
}
What will be the equivalent translation for build.gradle.kts?
Edit : I was able to copy the file using
task<Copy>("copyDdlSchemas") {
from("${brazilGradle.path("[ABC]pkg.src")}")
into("${brazilGradle.buildDir}/schema")
}
Need help with syntax to upload it to jar.
If what you want is the kotlin gradle equivalent of the sourceSets section in the question, it'll look like below:
sourceSets["main"].resources {
srcDir("${brazilGradle.buildDir}/schema")
include("src/*")
}
Once the files are part of the source set, they'll automatically get included in the jar file generated by the default jar task.
Related
I have an appium project written in kotlin and a build.gradle.kts. I'm using InteeliJ but also need to invoke the tests from the command line.
I have a Datasource.kt file which I would like to access both in the code and in gradle; right now it's just duplicated in the build.gradle.kts.
How can I effectively share the Datasource.kt file so that I have a single source of truth throughout the project?
Code example:
if (Datasource.getValue("key").isFeatureEnabled()) {
// check that corresponding button exists
}
Gradle example:
tasks.test {
...
useJUnitPlatform {
if (!Datasource.hasSomeThings) {
println("Gradle excluding \"SomeThings\" tests tag")
excludeTags("SomeThings")
}
}
I am stuck with converting a groovy gradle script to kotlin script. I am trying to use pf4j in my project and have started converting their example build.gradle to .gradle.kts. Example can be found here: https://github.com/pf4j/pf4j/blob/master/demo_gradle/plugins/build.gradle
Since I got stuck I am trying it just for one plugin right now, however their example is applying the task to all subprojects. So be aware of the difference.
So I tried to replace their build example with the following gradle.kts file:
val pluginClass: String by project
val pluginId: String by project
val pluginProvider: String by project
val version: String by project
val pf4jVersion: String by project
dependencies {
implementation(project(":api"))
implementation("org.pf4j:pf4j:${pf4jVersion}")
annotationProcessor("org.pf4j:pf4j:${pf4jVersion}")
}
val buildPluginArchive = task("plugin", Jar::class) {
manifest {
attributes["Plugin-Class"] = pluginClass
attributes["Plugin-Id"] = pluginId
attributes["Plugin-Version"] = version
attributes["Plugin-Provider"] = pluginProvider
}
archiveBaseName.set("plugin-${pluginId}")
into("classes") {
from(sourceSets.main.get().output)
}
dependsOn(configurations.runtimeClasspath)
into("lib") {
from({
configurations.runtimeClasspath.get().filter { it.name.endsWith("jar") }.map { zipTree(it) }
})
}
archiveExtension.set("zip")
}
tasks {
"build" {
dependsOn(buildPluginArchive)
}
}
And it works and generates a zip, but the contents do not match the original. Firstly the lib folder does not only contain jar files, but also a folder structure (and more important a META-INF folder with MANIFEST.MF file that confuses the plugin loader). And it is missing the MANIFEST.MF in the classes/META-INF folder.
I suspect the issue being somwhere with this configuration in the original build.gradle:
into('classes') {
with jar
}
I just could not find any meaningful documentation about what "with jar" actually does or how to replicate the behavior in gradle.kts.
How can I get the same output as the demo with a gradle.kts configuration?
I just could not find any meaningful documentation about what "with jar" actually does
with is a method from the Jar task type. See the method details section of the Jar task, scroll to the bottom and you'll find information the with method. It's signature is:
CopySpec with(CopySpec... sourceSpecs)
Now if you were to look at the API documentation for Jar, you'll see that with actually comes from CopySpec which Jar implements thanks to its super class.
The jar part in with jar is referring to the task named jar which is created by the Java plugin.
With all of that said, a more idiomatic approach for the with part would be:
tasks {
val plugin by registering(Jar::class) {
into("classes") {
with(jar.get())
}
}
build {
dependsOn(plugin)
}
}
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 trying to get the new (alpha) android datastore using protobuf support configured in gradle using Kotlin DSL (build.gradle.kts). The first attempts are not generating any java source classes from the xxx.proto (made-up name) file that is present. The protobuf plugin is generating the correct android tasks, but running them generates nothing, so obviously the default setup is not finding the directory my initial xxx.proto file is located in. The existing doc is thin on gradle setup, especially for Kotlin Gradle DSL (most all the gradle doc from google so far is for groovy), and my initial attempts at defining the location of the xxx.proto file are not working.
Does anyone have or has anyone seen working gradle config that specifies a custom source directory for .proto file(s) using Kotlin (build.gradle.kts)?
Got it working after some experimentation and floundering, but a hack is involved. If anyone can suggest improvements, it would be appreciated. In case this is useful here are the config snippets from the working setup. Module is kotlin 1.4.21-2 multiplatform with android, ios64, and jvm targets, with more planned. It has the KMP default setup for source directories:
The .proto file is in src/androidMain/proto subdirectory.
build.gradle.kts snippets are below. All the changes are in the android block, except for the plugin of course:
plugins {
id("com.android.library")
kotlin("multiplatform")
id("kotlinx-atomicfu")
kotlin("plugin.serialization") version Versions.kotlinVersion
id("com.google.protobuf") version "0.8.14"
}
...
kotlin {
... no changes here
}
...
android {
...
sourceSets {
...
getByName("main") {
manifest.srcFile("src/androidMain/AndroidManifest.xml")
java.srcDirs("src/androidMain/kotlin")
assets.srcDirs(File("src/commonMain/resources"))
withGroovyBuilder {
"proto" {
"srcDir" ("src/androidMain/proto")
}
}
}
}
protobuf {
protoc {
artifact = "com.google.protobuf:protoc:4.0.0-rc-2"
}
plugins {
id("javalite") { artifact = "com.google.protobuf:protoc-gen-javalite:3.0.0" }
}
generateProtoTasks {
all().forEach { task ->
task.builtins {
id("java") {
option("lite")
}
}
task.plugins{
}
}
}
}
dependencies {
api("com.google.protobuf:protobuf-javalite:4.0.0-rc-2")
implementation("androidx.datastore:datastore:1.0.0-alpha05")
...
}
}
Note the withGroovyBuilder hack in the android sourceset - the srcdir definition is required for the plugin to find the .proto file I had, but in the current version of the plugin I couldn't figure out the correct Kotlin DSL syntax. Seems like the plugin needs to define a Kotlin extension function to make this work better.
It would be really nice if instead of requiring this stuff, that the datastore stuff could use the protobuf serialization available with kotlinx.serialization, and skip this java code generation step in gradle all together. But I'm sure that's down the road...
Anyway, thanks in advance if anyone has improvements etc...
Using IntelliJ to open a build.gradle file, in the "Import Project from Gradle" window, the "Excluded Roots" are pre-populated with the .gradle and build directories.
How do I specify what directories should be excluded (or not excluded) in the build.gradle file?
Specifically I am using a protocol buffer plugin that places generated sources in the /build/generated-sources/ directory. If the build directory is excluded then my source class do not see the generated classes.
Details: IntelliJ 12.1.3, Gradle 1.4
As shown in the Gradle Build Language Reference, you can configure the idea.module.excludeDirs property, which is of type List<File>. Apparently IDEA doesn't support including subdirectories of excluded directories, so you'll have to exclude all siblings of build/generated-sources. For example:
idea {
module {
excludeDirs = [file(".gradle")]
["classes", "docs", "dependency-cache", "libs", "reports", "resources", "test-results", "tmp"].each {
excludeDirs << file("$buildDir/$it")
}
}
}
If supported by the Protocol Buffer plugin, it may be easier to put the generated sources into a place outside build, and make that place known to the clean task (e.g. clean.delete "generated-sources").
Another solution. Works with Idea 13.
idea.module {
excludeDirs -= file(buildDir) //1
buildDir.listFiles({d,f->f != 'generated-sources'} as FilenameFilter).each {excludeDirs += it}} //2
Remove buildDir from excludeDirs.
Exclude each buildDir child (except generating-source).
If you are using the Gradle Kotlin DSL, use the following snippet:
idea {
module {
excludeDirs.add(file("..."))
}
}
for exclude folder in module i'm use
idea {
module.apply {
val file = file("$projectDir/node_modules")
val exclude = HashSet<File>(excludeDirs)
exclude.add(file)
excludeDirs = exclude
}
}