JP Sugarbroad
09/26/2025, 11:57 PM> Task :redacted:kspKotlin FAILED
e: [ksp] Unknown error processing element
e: [ksp] io.micronaut.inject.processing.ProcessingException
I don't suppose there's more detail than this? Maybe a stack trace?atlantis210
09/30/2025, 5:38 AMursus
10/07/2025, 5:38 PMMaya
10/08/2025, 8:03 PMRobert Jaros
10/10/2025, 4:49 AMebtokyo
10/14/2025, 6:18 AMZac Sweers
10/22/2025, 2:33 AMMaya
10/22/2025, 5:10 PMeygraber
10/22/2025, 5:58 PMkotlin.native.enableKlibsCrossCompilation == false?jamireh
10/24/2025, 8:55 PMSwati Bajaj
10/29/2025, 10:31 AMSwati Bajaj
10/29/2025, 3:30 PMjamireh
10/30/2025, 12:13 AMRey (Kingg22)
11/01/2025, 6:13 PMMaya
11/04/2025, 8:39 PMarnaud.giuliani
11/05/2025, 4:36 PMResolver.getDeclarationsFromPackage() to scan annotations from other modules. It works in KSP 2.3.1 & Android apps (multi modules).
For KMP apps, it stops working since 2.1.20-1.0.31 & KSP1.
When switching to KSP2, other modules' annotations are not seen from the commonMain task. Seems to appear in the android detected element, where it should not (I'm scanning an element declared in commonMain generation).
This project uses KSP. The data module should allow to scan external module and associate them. The Data Module is not detected since KSP2 version.
I opened the issue => https://github.com/google/ksp/issues/2695 (sample project attached)
Let me know if it's a config problem. Any help is appreciated 🙂 🙏rocketraman
11/05/2025, 5:18 PMMaya
11/06/2025, 8:31 PMRey (Kingg22)
11/06/2025, 10:13 PMZac Sweers
11/10/2025, 6:41 PMdependencies {
add("kspCommonMainMetadata", project(":test-processor"))
add("kspJvm", project(":test-processor"))
}
However, I'm finding this to have a couple problems
1. The kspCommonMainMetadata task never appears to run unless explicitly depended on. This has been pointed out in the issue tracker it seems: https://github.com/google/ksp/issues/567#issuecomment-2609469736
2. It appears that processors in specific targets run on all sources (the complete set of target and common sources), which results in redeclaration/duplication issues for any sources in commonMain.
My questions on this I guess are
• Should kspCommonMainMetadata be configured to always run? Or at least if it has processors on its classpath? Seems a longstanding footgun that it's inert by default without some manual gradle fiddling
• Should there be a way to limit processing in specific targets to only run on sources defined in that source set, rather than the full set? I don't see a means currently for processors to handle this scenario (no means of detecting source set of origin, etc)
In general, it appears strongly to me like KSP on common sources is essentially only viable if you don't use the same processors in multiple source sets and know how to do the above gradle task wiring trick to force it to run. Happy to file issues for each of the above bullets toozsmb
11/10/2025, 7:53 PMksp("coordinates-go-here") solution, the new way of several declarations, per source set, all stringly typed is very tedious and error-prone 😞
I think it would be a safe assumption, at least by default, that I want to apply KSP to all platforms I have set up? I assume there are stats about the most used processors, it would be great to take a look at what their normal setup code looks like and if something could be done to simplify this for the happy path at least.Francisco Barreiras
11/11/2025, 12:00 AMvishnurajeevan
11/12/2025, 4:49 PM@ColumnInfo(name = "is_working")
var isWorking: Boolean? = nullFrancisco Barreiras
11/12/2025, 9:44 PMKonstantin
11/16/2025, 12:45 PMdead.fish
11/18/2025, 8:56 AM@SerialName("foo")
val foo: String
are only covering the annotation, but not the property declaration.Javier
11/21/2025, 12:47 PMMaya
11/21/2025, 5:40 PMMarcel
11/27/2025, 8:52 PMKonstantin
11/28/2025, 4:44 AM