Factory generation: provide a way to disable it in androidTest about anvil HOT 12 CLOSED

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.

from anvil.

You should not use Anvil and Dagger at the same time. You only need to use one of them. You also shouldn't use Anvil in modules that have @Component. Anvil should actually fail. I recommend to disable generating factories with Anvil in this module.

from anvil.

I'm not, I'm only using Dagger in test source set. How am I gonna create the component otherwise? There is not components in the main source set.

Are you saying I should use the old way of wiring Dagger modules in androidTest - including them manually in TestComponent. That's exactly the problem this project is trying to solve, no?

from anvil.

There are limitations:

This feature can only be enabled in Gradle modules that don't compile any Dagger component. Since Anvil only processes Kotlin code, you shouldn't enable it in modules with mixed Kotlin / Java sources either.

from anvil.

Why not implement it the way that allows to enable/disable the factoryGeneration(and potentially other generations besides hints) per android variant?
One way to do it is read value override from ext on KotlinCompile task, which users can then modify via tasks container

from anvil.

For now this isn't supported. We have a fairly large codebase and didn't need this feature ourselves, yet. I'd suggest to create a separate feature request for that.

from anvil.

from anvil.

In modules using @Component we use Dagger like before. Only modules not using @Component turn this feature with Anvil and remove the Dagger annotation processor.

from anvil.

Thanks for the PR, but I'm very hesitant about this solution. I'd rather see this configurable through a DSL. At the same time I'm still not convinced this feature is needed at all. I think configuring this on a module level is good enough. If you only want to toggle this feature on and off for specific variants you can always create a separate Gradle module and move the code there.

from anvil.

1. It is possible to register anvil extension instead of named property, since tasks are ExtensionAware
2. Creating a separate module just to run test is modularity for the sake of modularity - no actual benefit
3. For me personally it's easier(both short and long term) to maintain a fork with the feature than having to make separate modules just to test my code

from anvil.

Given that there are workarounds and it's totally fine to simply use the Dagger annotation processor in this module I'm closing this issue. I don't plan to support that feature.

from anvil.

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.

from anvil.