Factory generation: provide a way to disable it in androidTest

I have module which uses anvil Factory generation for it’s main source set and an androidTest source set which wants to generate(with Dagger) TestComponen" and get the dependencies from it to test them.

Currently this leads to an error inside androidTest compilation, because Factories for @Provides functions in a TestModule generated twice(by Dagger and Anvil).

Currently I’m using a wierd workaround(which is another Anvil bug I believe): If I mark @Provides functions in a TestModule as internal, dagger generates Factories with different names for them, and so the duplicate class exception doesn’t happen.

[vRallev]

This ticket can now be properly implemented, because with Kotlin 1.5 we have different compiler plugin classpaths for each variant. No Gradle build tool details need to leak into the compiler plugin anymore.

[marcellogalhardo]

Hey @vRallev - I would like to ask you to reconsider this functionality. I believe a way to disable Anvil Factories only on specific source set (in this case, Android Test) to use Dagger KAPT instead would be a very valuable feature.

For context, I will share some rounded numbers of my current project (real world case):

Our current project has around 1KK LOC and is divided into two types of modules: features and libraries. Today we have a total of 230 modules where around 60 are libraries and 100 are features (approximated number: we do have other modules for pipeline, sample apps, automation, etc, etc). Unfortunately, some of those feature modules are bigger than we would like it to be and have around ~70K LOC, which we are trying to split into more libraries.

We applied Anvil Factories on dozen of libraries modules (we are been very careful) and we manage to get an impressive reduction of an average of 50% per module and stop KAPT stubbing issues! Now we are trying to apply to our features but those modules contains UI Tests and those require a test @Component which can only be produced by Dagger KAPT.

The proposed workarounds are not doable to us for the following reasons:

• Use Dagger KAPT instead of Anvil Factories: in our tests we are getting impressive results - our contained feature experiment went from 35s (Dagger KAPT) to 18s (Anvil-only) which is compatible with the number we are seeing in the libraries. Our top 5 slower modules are feature modules and their build time goes from 2m25s to 1m59s. If we get half of the improvements we are seeing (25%) this would be already fantastic.

• Creating a separated UI Test module: this would increase our modules into at least +100 (one per feature module) and require heavy work to move hundreds of UI Test files around to those new modules with their required configurations. This will also require additional infrastructure work due to some limitations we have today (not relevant here, as this is not a reality for most projects).

• Maintain a fork of the library: this is something we would like to avoid if possible.

Let me know if I can give any extra details that could help us to make a good case in favor of this feature.