I'm trying to convert some task configuration in my Gradle plugin from Groovy to Kotlin. All of the examples I've found are about normal build scripts, and that approach doesn't seem to directly translate to plugin usage. My attempt below:
class JavaConventionsPlugin : Plugin<Project> {
// ...
fun configureBasicJavaOptions(project: Project) {
project.tasks.withType<JavaCompile> {
options.encoding = "cp1252"
options.warning = false
}
}
}
produces these errors:
Type mismatch: inferred type is () -> Unit but Class<TypeVariable(S)!>! was expected
Unresolved reference: options
Variable expected
What the right way to do this?
I'm not sure if this is the way, but it seems to work:
private fun configureBasicJavaOptions(project: Project) {
project.tasks.withType(JavaCompile::class.java) { t ->
t.options.encoding = "cp1252"
t.options.isWarnings = false
}
}
Related
Shadowjar's docs say to do this:
shadowJar {
configurations = [project.configurations.compileClasspath]
}
This appears to be in Groovy. If I run this in my Kotlin based gradle project, I get the following error:
Type mismatch:
inferred type is
Array<NamedDomainObjectProvider<Configuration>>, but
(Mutable)List<FileCollection!>! was expected
How can I perform this in Kotlin?
The equivalent would be:
tasks {
shadowJar {
configurations = listOf(project.configurations.compileClasspath.get())
}
}
The call to .get() is required because the return is NamedDomainObjectProvider<Configuration>. The Shadow plugin does not appear to support the lazy properties Gradle provides.
I've a java project that is built using gradle kotlin dsl.
Now I want to use gradle-avro-plugin like this https://github.com/davidmc24/gradle-avro-plugin#alternate-usage
In kotlin dsl I have written the same logic as below -
plugins {
java
id( "com.github.davidmc24.gradle.plugin.avro") version "1.0.0"
}
dependencies {
implementation ("org.apache.avro", "avro", "1.10.1")
}
val generateAvro = tasks.register<com.github.davidmc24.gradle.plugin.avro.GenerateAvroJavaTask>("generateAvro") {
source("src/avro")
this.setOutputDir(file("dest/avro"))
}
configure<org.gradle.api.tasks.compile.JavaCompile> {
this.source = fileTree(generateAvro)
}
The above code is returning below error when I run grade compileJava-
> * What went wrong:
Extension of type 'JavaCompile' does not exist. Currently registered extension types: [ExtraPropertiesExtension, DefaultArtifactPublicationSet, SourceSetContainer, ReportingExtension, JavaPluginExtension, JavaInstallationRegistry, JavaToolchainService, DistributionContainer, JavaApplication, DefaultAvroExtension]
How can I fix this error?
I had similar issues, what worked for me was:
plugins {
id("com.github.davidmc24.gradle.plugin.avro") version "1.2.0"
}
dependencies {
implementation("org.apache.avro:avro:1.10.1")
}
tasks.withType<com.github.davidmc24.gradle.plugin.avro.GenerateAvroJavaTask> {
setOutputDir(file("src/dest/dir/"))
}
The important thing is I did not registered a new task, just specified a new destination directory for each task with the type GenerateAvroJavaTask
I am using Gradle 6.0.1 and JDK12 with preview features.
Having the following configuration to be able to compile, run and test:
tasks.withType(JavaCompile) {
options.compilerArgs += "--enable-preview"
}
tasks.withType(Test) {
jvmArgs += "--enable-preview"
}
tasks.withType(JavaExec) {
jvmArgs += '--enable-preview'
}
That works fine for all except javadoc generation that I defined as follows:
task generateJavadocs(type: Javadoc) {
source = sourceSets.main.allJava
options.jFlags("--enable-preview")
}
When running gradle generateJavadocs I receive compilation errors for the new switch expressions. Has anybody made it work with Javadoc?
I had faced the same problem with preview features of JDK 14 (and Gradle 6.3). This has worked for me:
javadoc.options {
addBooleanOption('-enable-preview', true)
addStringOption('-release', '14')
}
In your case, try:
task generateJavadocs(type: Javadoc) {
options {
addBooleanOption('-enable-preview', true)
addStringOption('-release', '12')
}
}
This answer enhances Manfred's answer and is for anybody who is trying to set the javadoc args using gradle's kotlin api. It took me awhile to figure out that access to addStringOption and addBooleanOption requires a cast.
tasks.withType<Javadoc> {
val javadocOptions = options as CoreJavadocOptions
javadocOptions.addStringOption("source", "14")
javadocOptions.addBooleanOption("-enable-preview", true)
}
I have a multiplatform kotlin library project that publishes to maven and have been updating to the kotlin 1.3 multiplatform model and kotlin-dsl
The previous groovy gradle script has a modifyPom block, and i found an example here. However as soon as I add
val modifyPom : Closure<*> by ext
modifyPom(closureOf<MavenPom> {
// pom code in here
})
I get the same result no matter what is in the pom data, which is that the call of the modifyPom groovy closure breaks the build with a very vague error:
Build file '<path>\build.gradle.kts' line: 47
Open File
In other words the line number of the call of modifyPom groovy Closure, but nothing about the actual error.
I am using Gradle 5.0. Any help appreciated.
So - in Groovy I had this block for configuring POMs, and it worked just fine:
project.publishing.publications.forEach { publication ->
publication.pom.withXml {
def root = asNode()
root.appendNode("name", "libui")
root.appendNode("description", "Kotlin/Native interop to libui: a portable GUI library")
root.appendNode("url", POM_SCM_URL)
root.children().last() + {
licenses {
license {
name "MIT License"
url POM_SCM_URL
distribution "repo"
}
}
developers {
developer {
id "msink"
name "Mike Sinkovsky"
email "msink#permonline.ru"
}
}
scm {
url POM_SCM_URL
connection POM_SCM_CONNECTION
developerConnection POM_SCM_DEV_CONNECTION
}
}
}
}
And how to convert it to Kotlin DSL?
Edit:
Well, was answered in https://github.com/JetBrains/kotlin-native/issues/2372
In Gradle Kotlin DSL it becomes:
project.publishing.publications.withType<MavenPublication>().forEach { publication ->
with(publication.pom) {
withXml {
val root = asNode()
root.appendNode("name", "libui")
root.appendNode("description", "Kotlin/Native interop to libui: a portable GUI library")
root.appendNode("url", POM_SCM_URL)
}
licenses {
license {
name.set("MIT License")
url.set(POM_SCM_URL)
distribution.set("repo")
}
}
developers {
developer {
id.set("msink")
name.set("Mike Sinkovsky")
email.set("msink#permonline.ru")
}
}
scm {
url.set(POM_SCM_URL)
connection.set(POM_SCM_CONNECTION)
developerConnection.set(POM_SCM_DEV_CONNECTION)
}
}
}
This problem was fixed by changing the definition of modifyPom to
val modifyPom : Closure<MavenPom> by ext
That fixed the original problem as posted, and the pom is now being modified. If anyone needs help, add a comment and hopefully I will notice
I searched for plugins and tutorials but neither of them worked in the given context:
I'd like to generate server-side Java classes from a list of given WSDL files. They have to be generated with Axis 1.4 and Java 1.7.
My half-working code is the following:
configurations {
axisGenAntTask
}
task genWsdlClasses() {
doLast {
def wsdlDir = file(axisInputDir)
def wsdlFiles = new FileNameByRegexFinder().getFileNames("${wsdlDir}", /.*\.wsdl/)
wsdlFiles.each { String wsdlFile ->
ant.echo(message: "Generating Classes for use with WSDL")
ant.taskdef(
name: "genClassesFromWSDL",
classname: "org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask",
classpath: configurations.axisGenAntTask.asPath
)
ant.genClassesFromWSDL(
url: wsdlFile,
output: file(cxfOutputDir)
)
}
}
}
tasks.withType(JavaCompile) {
dependsOn genWsdlClasses
}
dependencies {
axisGenAntTask "org.apache.axis:axis-ant:1.4",
"org.apache.axis:axis:1.4",
"org.apache.axis:axis-jaxrpc:1.4",
"axis:axis-wsdl4j:1.5.1",
"commons-codec:commons-codec:1.3",
"commons-logging:commons-logging:1.1.1",
"commons-discovery:commons-discovery:0.2"
}
However, a generated CustomException class doesn't extend Exception, thus it is not throwable and Java code compilation isn't working (see similar question here: Exception classes generated using Axis2 wsdl2java don't extend Exception).
Somehow I would just have to tell ant.taskdef not to "unpack" the classes, as I read in the referenced SO-question, but the mentioned arguments are from Axis 2, not from the needed Axis 1.4 though.