can a annotation processor get the default values of fields ?

hi. I added

id 'org.jetbrains.kotlin.kapt' version '1.3.11'

to my

plugins

block, but it seems the

kapt

configuration is still missing. i always get an error

Could not find method kapt() for arguments [com.github.dzuvic:jtsgen-processor:0.4.0] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

Any idea?

This should work:

kapt {
    arguments {
         arg("kapt.kotlin.generated", yourDir)
    }
}

Is there a way to generate kotlin code in an agnostic module in an mpp project? kapt() is not available as it depends on javac

the interesting bits are in the

kgl-opengl/build.gradle.kts

and

buildSrc

Does anybody have a good idea how one could use annotations to "indirectly annotate" a class which isn't in your module? I was trying something like this:

import io.ktor.http.Url

@JSON
typealias Url = Url

Then in the annotation processor I could access the aliased type and apply the annotation logic there. Unfortunately that doesn't work with source-only annotations.

you likely want a standalone AOP solution like AspectJ

Hey everyone, I am looking for a sample or best practices to test an annotation processor with Kotlin. I’ve something that works quite well for Java and was wondering how I could do the same with Kotlin (knowing that I’ll probably have to do something kotlin specific in there)

Where are kotlin stdlib's annotation processors defined?

So like compile-testing is running the Java Compiler for testing annotation processors, can I do similar with kapt? https://github.com/google/compile-testing Or only through command line interface?

Are there plans to migrate from

com.sun.tools.javac.main.JavaCompiler

(etc.) to

javax.tools.JavaCompiler

(etc.)? The former causes a lot of issues when using Kapt in-process on Java 9+. … oh, the Kotlin Compiler uses it too 😕

Do someone had problems with kapt not running for unit tests in a module?

if I add

kapt "io.arrow-kt:arrow-meta:$arrow_version"

to jvmMain for example, it complains it doesn't know what kapt is. I guess perhaps that's because the kapt plugin doesn't understand the mpp layout?

Is it possible to have some kapt dependence declared as API? I have a module with some dagger scopes and I would like to avoid the boiler plate in all modules that depend of that module of declare dagger dependency again.

does anyone have an example of passing kapt arguments for a single Android buildType/variant?

we use gradle parallel

Any thoughts or suggestion?

Probably because they're not copied to the stubs

have anyone noticed that

kapt

in kotlin

1.3.30

picks up wrong build cache entries? In our case build cache is populated only on CI builds and kapt sometimes picks up results from

master

branch that has new generated classes and fails local branch build with message "Can't find this new generated class type."

1.3.31 is broken for me, I get this while compiling:

Execution failed for task ':common:kaptDebugKotlin'.
> Could not resolve all files for configuration ':common:_classStructurekaptDebugKotlin'.
   > Failed to transform file 'classes.jar' to match attributes {artifactType=class-structure, org.gradle.usage=java-runtime-jars}
      > Execution failed for StructureArtifactTransform: /Users/nicklas/.gradle/caches/transforms-2/files-2.1/3b26390363c49f3a73506646bd39f9c5/jars/classes.jar.
         > java.lang.IllegalArgumentException (no error message)

Are there any plans to optimize Kapt speed? In recent tests Uber found out that it almost doubles compilation times. I have similar experience in my project where without Kapt the build is significantly faster. https://eng.uber.com/measuring-kotlin-build-performance/

With the changes made to kapt in 1.3.31, kotlin does some aggressive caching to decrease incremental built times. Unfortunately, some annotation processors and kapt don’t work well together and the cache is not properly invalidated in some conditions. - Deleted classes with

@Inject

may still have code generated for it. - Moved classes with

@Inject

may still have code generated in the old location. This behavior is enabled by default in Kotlin 1.3.31. Is there something I need to configure to ensure the cache is properly invalidated? This is causing some issues for my team, especially when we switch between branched.

What did change in recent kapt/Kotlin/Gradle updates which causes that annotation processors are no longer being run when using a

project

kapt dependency? old (Gradle 5.2.1, Kotlin 1.3.21)

kapt(project(":fluid-json-annotation-processor"))

runs kapt just fine using processor from different subproject new (Gradle 5.4.1 with modules, Kotlin 1.3.31)

kapt(project(":fluid-json-annotation-processor", "compile"))

annotation processor is not used anymore and no error 😕

are there any example about how to add compiler warnings using kapt?

Experimenting with annotation processors - is there an easy in way to figure out whether an annotated property is nullable? The mirror APIs don’t have any information on this. I looked a bit into kotlinx metadata library, but I must be using it in a wrong way as all the flags I’m getting back are nullable … (the flag absolute value is 551). Here’s the code I’m using to gather the flags:

val metadataAnnotation = typeElement.getAnnotation(Metadata::class.java)
        val header = KotlinClassHeader(
            metadataAnnotation.kind,
            metadataAnnotation.metadataVersion,
            metadataAnnotation.bytecodeVersion,
            metadataAnnotation.data1,
            metadataAnnotation.data2,
            metadataAnnotation.extraString,
            metadataAnnotation.packageName,
            metadataAnnotation.extraInt
        )

        val metadata = KotlinClassMetadata.read(header)
        when (metadata) {
            is KotlinClassMetadata.Class -> {
                metadata.accept(object: KmClassVisitor()  {
                    override fun visitProperty(
                        flags: Flags,
                        name: String,
                        getterFlags: Flags,
                        setterFlags: Flags
                    ): KmPropertyVisitor? {
                        val nullable = Flag.Type.IS_NULLABLE(flags)
                        Logger.logW("* visiting property $name, flags: $flags, nullable: $nullable")
                        return super.visitProperty(flags, name, getterFlags, setterFlags)
                    }
                })
            }
            else -> {
                Logger.logW("bummer ... not a class: $metadata")
            }
        }

Anyone can see anything?

Anyone using incremental kapt in multi-module setup? I’m noticing that it actually makes build times worse if one of core modules is invalidated. For example, changing a feature module causes 70-90 second kapt in the main app module. (Project has over 50 modules)

when I migrate my android project from kotlin 1.3.11 to 1.3.31, all gradle modules that use

kaptTest

failing until I

apply plugin 'kotlin-kapt'

— is that really necessary? am I doing it right? any idea where i can find documentation / release notes about breaking changes like these? 🙂

Does anyone know why the gradle Task kaptKotlin may fail ?