Does a processor applied to a given module have visibility on elements that are invisible to the source for that module if those annotated elements exist within a dependency? What I'm looking to accomplish is to support generation of some classes internal to some collection of child modules, but then provide a simple way for resolving the generated classes in a consumer module. The mechanism for this would probably be by generating a map where keys are an interface the generated classes implement, where the keys are internal to the same places the generated classes (and thus only used in the modules where internal visibility applies), but I'm looking to have one central registry if possible, as that could itself also be generated. So: • Module A depends on Module B. • Module B contains some elements annotated with

@XYZ

. When a processor resolving elements annotated with

@XYZ

is applied to Module A, will the resulting processor execution resolve those elements from Module B that have been annotated with

@XYZ

?

you won’t be able to retrieve these annotated symbols in module B with KSP’s

getSymbolsWithAnnotation

API, if you can find a way to get these symbols somehow, then you can still process them, but I won’t be optimistic on this.

you won’t be able to retrieve these annotated symbols in module B with KSP’s 

getSymbolsWithAnnotation

 API

just to clarify: this is because the sequence of elements from the resolver wouldn't include them? thanks so very much for the ridiculously quick reply btw 🙂

yes, the resolver will only look up in source code files in the compile module for annotated symbols. Theoretically you can get the symbols from dependencies with fully qualified name to process but I assume that is not practical for real use.

so the limiting factor here for me isn't the visibility, but rather just the module boundaries

that API is still not a general purpose API, if that works it will be great 🙂

well - happy to give it a go! if it doesn't work, i'll just find another way to the end result 🙂

I have done a trick where I used a file annotation (, or an annotation on a typealias) that have a KClass<*> parameter. It offers the possibility to reference classes from outside the compilation module, and get the KSClassDeclaration of those classes. I'm not sure, but maybe it can help you?

good to know that's another option! it looks like in your example, the use of your

KustomExportGenerics

annotation is in the module where the processor is applied, right? so to conform it to my described scenario above: •

@file:KustomExportGenerics

is used in Module A, referencing classes from Module B. • Processor is applied to Module A but can resolve

KSClassDeclaration

instances for the classes in Module B that are referenced in the

KustomExportGenerics

Yes, that's it.

great 🙂 will make a note of this approach and see if it helps me