I'm upgrading from deprecated gradle properties, and instead of referencing the File jar.destinationDir, I'm using the DirectoryProperty jar.destinationDirectory
But because I need a java.nio.file.Path object, my code changes from
jar.destinationDir.toPath()
into
jar.destinationDirectory.asFile.get().toPath()
Is there some groovy way to omit at least the .asFile.get()?
Related
I am trying to convert build.gradle to kotlin dsl. Using gradle 7.4.1.What the right way to declare custom configuration. For custom configuration like
configurations { grafana }
sourceSets { grafana }
and within dependencies block
grafanaImplementation "org.slf4j:slf4j-simple:1.7.36"
grafanaImplementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
grafanaRuntimeOnly "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
While I am in kotlin-dsl I am doing
val grafana by configurations.creating
val grafanaSourceSet = sourceSets.create("grafana")
and within dependency block
grafana("org.slf4j:slf4j-simple:1.7.36")
grafana("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
When I try to put grafanaImplementation/ grafanaRuntimeOnly within kotlin dsl, it fails.
What is the equivalent of grafanaImplementation/ grafanaRuntimeOnly within kotlin dsl
Quick fix
When you do
val grafanaSourceSet = sourceSets.create("grafana")
behind the scenes Gradle will create the required configurations, grafanaImplementation, grafanaRuntimeOnly, etc, so you can use them without error like this:
val grafanaSourceSet = sourceSets.create("grafana")
dependencies {
"grafanaImplementation"("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
"grafanaRuntimeOnly"("org.slf4j:slf4j-simple:1.7.36")
}
This approach is more like how Groovy works - it basically disables type-checking and the strings will be evaluated during Gradle execution.
Generated DSL accessors
However, string-typing is not why we like Kotlin! We want type-safety and auto completion hints. That's exactly what we see with the implementation() and runtimeOnly(). So how do we get them for grafanaImplementation() and grafanaRuntimeOnly()?
Basically, Gradle will scan the registered config and when it sees that a plugin creates an implementation configuration, it generates Kotlin DSL accessors. However, it can't generate accessors for the build.gradle.kts that contains the definition for the accessors... that's too late. So we need to define the config earlier. We can do that with a buildSrc plugin.
buildSrc Grafana convention plugin
Set up a buildSrc project (this is covered more in the Gradle docs or other StackOverflow answers)
Create a pre-compiled script plugin for Grafana config
// $projectRoot/buildSrc/src/main/kotlin/grafana.convention.gradle.kts
plugins {
// using 'sourceSets' requires the Java plugin, so we must apply it
java
}
val grafanaSourceSet = sourceSets.create("grafana")
Note that this convention plugin is quite opinionated as it applies the Java plugin. In more complex setups you might want to instead react to the Java plugin, rather than always applying it.
Now apply the convention plugin, and Gradle will generate the Kotlin DSL accessors!
// $projectRoot/build.gradle.kts
plugins {
id("grafana.convention")
}
dependencies {
// no string-typing needed!
grafanaImplementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
grafanaRuntimeOnly("org.slf4j:slf4j-simple:1.7.36")
}
I have a Gradle 5.3 build script using Kotlin DSL, similar to this:
plugins {
`kotlin-dsl`
`java-library`
}
group = "my.company"
version = "1.2.3"
Here, version= resolves to org.gradle.api.Project.setVersion.
Now, farther down, I'd like to do this (porting from a Groovy DSL build file):
tasks.named<Jar>("jar") {
manifest {
attributes(
"Product-Version" to version
)
}
}
Here, version resolves to AbstractArchiveTask.getVersion -- not what I want (and also deprecated)!
Figuring I could use Kotlin's qualified this, I tried to use
"${this#Project.version}"
instead (NB: the extra string wrapping gets rid of an additional type error), but I get Unresolved reference: #Project now.
How can I access the project version from within a Kotlin DSL expression?
The Gradle script doesn't seem to be nested inside Project but instead delegates accessors to its relevant properties. In fact, the top-level this is of type Build_gradle.
When those accessors are shadowed, variable project can be used; that is,
project.version
solves the issue at hand. As an alternative,
this#Build_gradle.version
is also valid but less readable.
There's an open source Gradle plugin that I use (in this case, it happens to be wuff). I have my own Gradle plugin, called Foo.
My foo plugin needs to peek into the configuration data for wuff - it depends on some values which are set there.
How do I get it?
Where does wuff set the values ? Is it in the wuff plugin object ?
You can get the wuff plugin reference as
if (project.plugins.hasPlugin('wuff')) {
wuffPlugin = project.plugins.findPlugin('wuff')
//access the config from wuffPlugin object.
}
When I try to use Jackson 2.1.1 with the following jar files (in Spring 3.2.2),
jackson-core-2.1.1.jar
jackson-annotations-2.1.1.jar
jackson-databind-2.1.1.jar
I get the following exception.
java.lang.ClassNotFoundException:
org.codehaus.jackson.JsonProcessingException
So I think, the class JsonProcessingException is contained by the jackson-core-asl-2.1.1.jar file (I'm not quite sure though) but I cannot see this file in the download. So where to get this file to resolve that exception?
jackson-all-1.9.8.jar contains necessary classes including the class org.codehaus.jackson.JsonProcessingException and JSON also works fine but I'm not sure this is perfectly compatible as I'm using classes from Jackson 2.1.1 for object mapping. Therefore I'm looking for the jackson-core-asl-2.1.1.jar file but I can't see such a JAR file. I can only see 1.x.x versions here.
In version 2.1.2, that class is called com.fasterxml.jackson.core.JsonProcessingException, and it's in the jackson-core jar. Jackson changed its packaging for version 2.0, along with numerous other things.
It seems you have some code that was written against an older version of Jackson, and is trying to load the class under an old name. You will need to either update this code, or use an old version of Jackson.
Use jackson-all-1.9.9 jar instead of the later versions(2.x.x.) of jackson-core, jackson-annotations and jackson-databind. Here is the link.
I am coverting an ant project to Maven. Using the class
weblogic.wsee.tools.anttasks.ClientGenTask
Ant was generating the classes from the WSDL. Example:
com.company.ArrayOfQualifyingActivity
But now using Maven plugin, it's creating
com.company.ArrayOfQualifyingActivitySequenceCodec
Has anyone else run into this before?
Edit:
Never mind. Resolved the issue. The previous clientgen was wrapping arrays of classes (for QualifyingActivity[] ) in a wrapper class.
The maven clientgen is not doing that. So I can use the QualifyingArray[] or String[] etc... as is.
Thanks