Например, у меня есть 3 модуля (A, B и C), где A зависит от B, а B от C (A-> B-> C).Модуль A является точкой входа для процесса сборки, никакой другой модуль не зависит от него, например: модуль приложения в приложениях Android.Модули A и C имеют одинаковый размер аромата и один и тот же набор ароматов (например, flav1, flav2, flav3, flav4 и т. Д.).Модуль B не имеет никаких вкусов.
Теперь возникает вопрос: как определить эти зависимости, чтобы они были «транзитивными» таким образом, чтобы модуль A i модуль C всегда совпадал по вкусу?
модуль A (flav1) -> модуль B-> модуль C (flavor1)
модуль A (flavor2) -> модуль B -> модуль C (flavor2)
модуль A (flavor3) -> модуль B -> модуль C (flavor3))
и т. Д.
Если бы все 3 модуля имели одинаковые варианты, Gradle автоматически сопоставил бы их, но, поскольку B не имеет вариантов, возникает ошибка, которая уже описана в этом вопросе: Единственный модуль аромата, основанный на мультиаккумной библиотеке в Gradle , но ответы не очень актуальны: (
Что мне нужно с этим, так это теперь, если я запущу ./gradlew buildFlavor1Debug для получения модуля A иC с flavour1, и вообще, чтобы все модули, которые знают об ароматах, соответствовали вкусу, указанному в начале цепочки, и тем модулям, которые не знают о ароматах, просто перенаправлять / игнорировать их.
проблема с отсутствующим DimensionStrategy «измерение» заключается в том, что требуется, чтобы аромат в зависимости был жестко запрограммирован / исправлен, а не динамически основан на точке входа сборки, например:модуль B -> модуль C (flavor1)
модуль A (flavor2) -> модуль B -> модуль C (flavor1)
модуль A (flavor3) -> модуль B -> модуль C(flavour1)
и т. д.