We Keep Coding

Getting the resource path of the java project from a custom gradle plugin

Trying to create a custom gradle plugin in java, how do i get the resources path from inside the task class?
public class MyCustomPlugin implements Plugin<Project> {
#Override
public void apply(Project project) {
project.getTasks().register("doStuff", CustomTask.class);
}
}
public class CustomTask extends DefaultTask {
// How do I get java project resources dir from here?
#Inject
public CustomTask(ProjectLayout projectLayout) {
directoryProperty = projectLayout.getBuildDirectory();
}
#TaskAction
public void execute() {
...
}
}

I would recommend to not get the directory inside the task, because the plugin that provides it might not be applied. Instead I would do it from within your plugin that registers the task, this way you can also ensure that the necessary plugin is actually applied. Gradle will display an error if the task is used without a value being assigned to the input that explains that nothing was assigned.
With the kotlin-dsl:
#CacheableTask
abstract class CustomTask : DefaultTask() {
#get:InputFiles
abstract val resources: FileCollection
//...
}
I cannot answer if #InputFiles is the right annotation for your use case, because I don't know what you want to do with the resource. Refer to the Gradle documentation for more information on the available annotations, and what they do.
plugins {
java
}
tasks.register<CustomTask>("customTask") {
resources.set(sourceSets.main.map { it.resources })
}
Notice the map {} which ensures that our task has a dependency on the processResources task, this is done automatically for us because we stick to the provider API of Gradle for everything.
Note that the resources are by default in one directory, but they don't have to be. This is why the resources are defined as SourceDirectorySet and not as Provider<Directory>. The same is true for anything that originates from the SourceSetContainer. It is easier to explain with Java source code: imagine you have Java and Kotlin, then you will have src/main/java and src/main/kotlin, hence, 2 directories. The former will have a **/*.java include filter, whereas the latter has a **/*.kt includes filter. If we just want to get all sources then we use sourceSets.main.map { it.java.sourceDirectories }, and if we want to get one of both it gets complicated. 😝

First, you'd have to ensure this is a Java project: either applying the "java" plugin from your plugin (project.getPluginManager().apply("java")), or only registering the task when the "java" plugin has been applied by the user (project.getPluginManager().withPlugin("java", ignored -> { project.getTasks().register(…); });).
You could then get the resources from the main source set:
SourceSetContainer sourceSets = project.getExtensions().getByType(SourceSetContainer.class);
// Use named() instead of get() if you prefer/need to use providers
SourceSet mainSourceSet = sourceSets.get(SourceSet.MAIN_SOURCE_SET_NAME);
SourceDirectorySet resources = mainSourceSet.getResources();
BTW, the best practice is to have tasks only declare their inputs and outputs (e.g. I need a set of directories, or files, as inputs, and my outputs will be one single file, or in one single directory) and have the actual wiring with default values be done by the plugin.
You could have the plugin unconditionally register the task, then conditionally when the "java" plugin is applied configure its inputs to the project resources; or conditionally register the task or unconditionally apply the "java" plugin, as I showed above.

You can access the sources through the project.sourceSets.
#Inject
public CustomTask(Project project) {
directoryProperty = project.projectLayout.getBuildDirectory();
sourceSet = project.sourceSets.main
}
See also the reference documentation here: https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_project_layout

Is onConstructor property of the Lombok's #[No|All|Required]ArgsConstructor annotation work Java 7 style only?

According to the documentation, Lombok has 3 annotations for constructor generation:
#NoArgsConstructor - generates an empty constructor;
#AllArgsConstructor - generates a constructor that initializes all
fields;
#RequiredArgsConstructor - generates a constructor that
initializes only final fields.
They all have an onConstructor property that allows you to specify the annotations with which the generated constructor should be marked.
According to the Javadoc, the syntax for this feature depends on JDK version (nothing we can do about that; it's to work around javac bugs).
Up to JDK7:
#NoArgsConstructor(onConstructor=#__({#AnnotationsGoHere}))
From JDK8:
#NoArgsConstructor(onConstructor_={#AnnotationsGohere}) // note the underscore after onConstructor
I am working on JDK8. However, only the JDK7 variant works for me, while the JDK8 variant does not work (a constructor without annotations is generated).
I checked on JDK11 - same result.
I check with Refactor -> Delombok -> #Constructors.
For example, like this:
#AllArgsConstructor(onConstructor = #__(#Deprecated))
public class SomeClass {
}
the following code is generated:
public class SomeClass {
#Deprecated
public SomeClass() {
}
}
But like so:
#AllArgsConstructor(onConstructor_ = #Deprecated)
public class SomeClass {
}
code like this is generated:
public class SomeClass {
public SomeClass() {
}
}
I noticed that the documentation on the Lombok site only contains a JDK7 style example.
The Javadoc is incorrect or am I doing something wrong?

I found, that it's not the Lombok's bug, it's Lombok IntelliJ plugin bug.
Constructor annotations add in compiled code.
Delombok tool of Lombok IntelliJ plugin incorrect convert Lombok's annotations to vanilla Java code.

Using Hibernate Validator Annotation Processor with Kotlin (and Gradle)

So I'm trying to get the Hibernate Validator Annotation Processor working in a Kotlin project, to check my JSR 380 annotations, with not much luck.
Unfortunately the documentation does not mention how to set it up with Gradle, and obviously with Kotlin we have to use "Kapt" to enable java annotation processors.
Hibernate Validator Annotation Processor Documentation: http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#validator-annotation-processor
Kapt Documentation: https://kotlinlang.org/docs/reference/kapt.html
I currently have the following config in my build.gradle file relating to the processor:
plugins {
id "org.jetbrains.kotlin.kapt" version "1.3.11"
...
}
apply plugin: 'org.jetbrains.kotlin.kapt'
...
dependencies {
implementation 'org.hibernate:hibernate-validator:6.0.14.Final'
implementation 'org.glassfish:javax.el:3.0.1-b09'
kapt 'org.hibernate:hibernate-validator-annotation-processor:6.0.14.Final'
...
}
kapt {
arguments {
arg('methodConstraintsSupported', 'false')
arg('verbose', 'true')
}
}
However whenever I build, I cannot see any output relating to the validator annotation processor and I do not get any build errors when deliberately applying an incorrect annotation (e.g. applying a #Min() annotation to a String field.
If someone could advise on how to get the processor working I would be eternally grateful! :)

I got this working in my build.gradle.kts like so (I'm using Kotlin Script as opposed to Groovy):
plugins {
...
id("org.jetbrains.kotlin.kapt") version "1.3.72"
...
}
dependencies {
...
kapt(
group = "org.hibernate.validator",
name = "hibernate-validator-annotation-processor",
version = "6.0.2.Final"
)
...
}
This correctly gave me errors when building, but only when I applied the validation annotation to the getter. When I was mistakenly applying it to just the constructor argument the validation did not work, and I saw no errors from the annotation processor. For example:
class Thing(
#get:AssertTrue
var name: String
)

Is it possible to use Lombok with Kotlin?

I have a Kotlin Gradle project. I added Lombok as a dependency and also registered it with kapt
compileOnly("org.projectlombok:lombok:$lombokVersion")
kapt("org.projectlombok:lombok:$lombokVersion")
I would like to use the #Slf4j annotation for automatic logger generation. It works for Java classes but not for the Kotlin ones.
Is using Kotlin and Lombok together even possible as of now? If I annotate a Kotlin class with #Slf4j and use log inside it I get
Unresolved reference: log
Evidently no annotation processing is applied.

Lombok does not run on your source code, but on the AST. Anyway, it is an annotation processor that is run at compile-time by the Java compiler. The Kotlin compiler does not use these annotation processors. See also the answer https://stackoverflow.com/a/35530223/2621917 straight from the horse’s mouth.

You cannot use annotation #Slf4j, but manually create its object in the class required.
Refer https://www.reddit.com/r/Kotlin/comments/8gbiul/slf4j_loggers_in_3_ways/

If all you want to use Lombok for is #Slf4j, then I'd suggest using kotlin-logging instead: https://github.com/MicroUtils/kotlin-logging
It's a simple wrapper around slf4j, so instead of annotating your class with #Slf4j, you use:
// Place definition above class declaration to make field static
private val logger = KotlinLogging.logger {}
// ...
logger.debug { "A message only logged if debug is enabled. With $variable support." }

Lombok's builder annotation support has been added to kotlin 1.8 as of late December 2022.
You can learn how to configure the plugin here.
In Short, add
plugins {
id 'org.jetbrains.kotlin.plugin.lombok' version '1.8.0'
id 'io.freefair.lombok' version '5.3.0'
}
to your Groovy/Gradle files, and/or take a look at the sample project.

It's not supported and, by the looks of things, it isn't going to be.

from kotlin 1.7.20 with K2 compiler it is possible.
https://kotlinlang.org/docs/whatsnew1720.html#support-for-kotlin-k2-compiler-plugins

For logging the best I could do - because #Slf4j did not work - was like creating abstract log class like:
package org.example
import org.slf4j.LoggerFactory
import org.slf4j.Logger
abstract class Log {
val log: Logger = LoggerFactory.getLogger(this.javaClass)
}
and usage:
package org.example
class MyClass {
companion object : Log() {}
#Test
fun someFun() {
log.info("Logging info")
}
}

I can't see how it would work without additional support from the lombok team.
Lombok is based on annotation processing so it runs during compilation time and runs on your source code, so I guess it assumes Java's syntax.

Is there a Java wrapper annotation?

Trying to find a way to wraps an object, which is auto generated based on some model with lots of getters and setters. For example:
class ObjectToWrap {
public int getIntA();
public int getIntB();
... // Tons of other getters
}
I have to create a wrapper that wraps this object and use some annotation that generates methods from ObjectToWrap for me. Code looks like the following:
class Wrapper {
private ObjectToWrap obj;
public int getIntA() {
return obj.getIntA();
}
public int getIntB() {
return obj.getIntB();
}
... // Tons of other getters
}
Is there an annotation to do this? I just don't want to make the code look lengthy.

Take a look at Project Lombok which has a #Delegate annotation which does exactly what you want.
#Delegate documentation
I think you would be able to do this:
import lombok.Delegate;
class Wrapper {
//the types field in the annotation says
//to only auto generate deleagate methods
//for only the public methods in the ObjectToWrap class
//and not any parent classes if ObjectToWrap extended something
#Delegate(types = ObjectToWrap.class)
private ObjectToWrap obj;
}

If you are using the maven build infrastructure with dependency management, you could have a dependent sub-project that collects the generated sources as-is (not as code). Another sub-project could then generate real sources out of them (source code transformation) as zip, which then could be imported by maven in the main project as pre-compile target.
On that basis you could use dynamic proxy classes, or even immediate generated classes.
The only other alternative would be to use the java scripting API, and do the business in JavaScript or so. Loosing the type safeness of java and lowering the software quality.
Unfortunately the alternative of hybrid usage of another JVM language I cannot consider productive. The very nice and powerful Scala still is too wild/complex/ticklish.