Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR]: Many unwanted build variants are created because of AndroidLibraryConventionPlugin #746

Open
2 tasks done
SimonMarquis opened this issue May 21, 2023 · 0 comments
Open
2 tasks done
Labels
enhancement New feature or request

Comments

@SimonMarquis
Copy link
Contributor

SimonMarquis commented May 21, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Describe the problem

The convention plugin AndroidFeatureConventionPlugin currently creates many unwanted build variants, which definitely has a negative impact on total build time.

This creates variants of libraries, where in fact, they are meaningless and detrimental because the code is always the same, and it forces consumers to be "variant-aware".

For example, the :core:domain module which should not have variants:

> ./gradlew :core:domain:tasks --group=build --quiet

------------------------------------------------------------
Tasks runnable from project ':core:domain'
------------------------------------------------------------

Build tasks
-----------
assemble - Assemble main outputs for all the variants.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles main outputs for all Debug variants.
assembleDemo - Assembles main outputs for all Demo variants.
assembleProd - Assembles main outputs for all Prod variants.
assembleRelease - Assembles main outputs for all Release variants.
[...]
compileDemoDebugSources
compileDemoDebugUnitTestSources
compileDemoReleaseSources
compileDemoReleaseUnitTestSources
compileProdDebugSources
compileProdDebugUnitTestSources
compileProdReleaseSources
compileProdReleaseUnitTestSources
demoDebugSourcesJar - Assembles a jar archive containing the sources of target 'demoDebug'.
demoReleaseSourcesJar - Assembles a jar archive containing the sources of target 'demoRelease'.
extractDemoDebugAnnotations - Extracts Android annotations for the demoDebug variant into the archive file
extractDemoReleaseAnnotations - Extracts Android annotations for the demoRelease variant into the archive file
extractProdDebugAnnotations - Extracts Android annotations for the prodDebug variant into the archive file
extractProdReleaseAnnotations - Extracts Android annotations for the prodRelease variant into the archive file
prodDebugSourcesJar - Assembles a jar archive containing the sources of target 'prodDebug'.
prodReleaseSourcesJar - Assembles a jar archive containing the sources of target 'prodRelease'.

Describe the solution

Remove the default "flavoring" of AndroidLibraryConventionPlugin, and centralize it in a dedicated AndroidFlavorsConventionPlugin.

Additional context

This also brings the question of "where" should @Module be declared.
For instance, in the :core:analytics module, we have the modules defined in the variants sourceSets (prod/demo). Even though the stub (for demo) and Firebase (for prod) is shipped in the main/default sourceSet which breaks the expectations of build variants to only contain the relevant code.
Having this module publish its variants, forces other modules dependending on it to also be variant-ware...

Here are two solutions:

  • (simpler) move the @Modules to the :app module, which is meant to be variant-aware.
  • (more "correct") move the @Modules to a :core:analytics:wiring module, which only the :app module will depend on.

Code of Conduct

  • I agree to follow this project's Code of Conduct
@SimonMarquis SimonMarquis added the enhancement New feature or request label May 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant