KotlinBuilder leaks dagger dependency into compilation.

[cgruber]

When using Dagger >2.21 which introduces a new inner class Component.Factory, compilations that involve dagger processing end up having an older version of Dagger (2.16), which is API incompatible (Component in both versions have different metadata about inner classes). This results in compile-time crashes during annotation processing.

This likely means that however kapt is being invoked, the builder itself is in the classpath, probably because the builder is invoking kapt in its process.

The correct action would be to isolate classloaders.

Possible backups would include:

• "shading" all of the third-party consumed libraries by the builder, so as not to conflate types. (good practice anyway)
• removing dagger and hand-rolling the dependency injection (crappy, but reduces the deps of the builder itself - it's mostly in kotlin anyway, so it might be feasible to use kotlinisms to reduce the cost of a service-locator-ish approach).
• Causing the dagger used to build the builder to be supplied externally, so users of the rules could control what dagger version was used in the infrastructure (a more mono-repo approach).

[cgruber]

Gonna suggest probably shading, as it's the simplest option, architecturally. Just changes the packaging step.

[cgruber]

This fix is released in https://github.com/cgruber/rules_kotlin/releases/tag/legacy-modded-0_26_1-01