Approach when usimg klassindex with library modules

[aymanson]

Hi,
I would like to discuss whats the appropriate way in using this library when I have dependencies library which have used the annotation. It seems like I cannot run kapt per modules or else I hit duplicated classes generated during gradle build. If I only run it in main app, how can I indicate the kapt should run on the modules as well?

[matfax]

Hi @aymanson
It's difficult to understand the problem without code. It's been a while since I've worked on this project so I don't remember exactly how Gradle and kapt behave in this scenario or how it was intended to work. It would be best if you can provide me access to the source code of your project or a simplified example that shows the problem.
In general, if multiple libraries use klassindex on the same classes, the generated index files might conflict because of their names. This could easily be fixed; it's just a companion variable in the preprocessor. But it depends on the use case. Are all libraries supposed to access the complete index or should each library access only the index of its own project?

[MairwunNx]

+1. The same problem. I don't know what i need to do with this bug. I believe that this class which contains references to classes should be generated in special packages for the project, so that there would be no conflicts with multi-modular projects. It may just happen that one module receives classes of another module, but not its own, because the same class path.

[MairwunNx]

@matfax what about storing class patches in meta-inf directory?

[matfax]

@MairwunNx I would appreciate it if you could provide me with more detailed information on how to reproduce the issue. I understand that it's about multi-modular projects but what's the underlying Gradle configuration and structure?

[matfax]

I think const val KAPT_KOTLIN_GENERATED_OPTION_NAME = "kapt.kotlin.generated" could have been used to avoid file conflicts, if that's what this multi-module issue is about. But I'll try to find an automatic method with the KSP overhaul. This could be done either by including the module path in the generation path or by merging all module indices, thereby creating a shared index. I'm inclined to use the second approach because the first approach might cause resolving issues.