Обработка аннотаций нескольких модулей Android

В многомодульном проекте Android обработка аннотаций по-прежнему выполняется в качестве первой задачи перед любой компиляцией, а затем запускается полная компиляция. Конечно, это делается для каждого модуля перед тем, как попасть в модуль app.

Представьте себе случай, когда некоторые дочерние модули зависят от других, компиляция завершится ошибкой, поскольку зависимый модуль пока не может найти определение для сгенерированных классов в модуле, от которого он зависит, просто потому, что они еще не были сгенерированы.

Мне интересно, есть ли способ использовать gradle или что-то еще, чтобы сначала выполнить обработку аннотаций всех дочерних модулей, а затем автоматически скомпилировать весь проект. Это означает, что если у меня есть 3 модуля, назовем их app, services и executors, где services зависит от executors.

Я ищу, чтобы дерево сборки шло в следующем порядке:

  1. обработка аннотации выполняется для всех модулей без компиляции
  2. затем вызывается полная компиляция проекта

Пока что я нашел несколько многообещающих выводов, используя параметр java compiler's -proc:{none;only}, где значение only должно вызывать обработку аннотаций без какой-либо дальнейшей компиляции. Я попытался передать этот option своему компилятору, но все равно компиляция идет последовательно дочерний модуль за дочерним модулем.

Любые идеи?


android java annotation-processing
person AouledIssa    schedule 28.05.2020    source источник
comment
Я готов назначить награду за это!   -  person AouledIssa    schedule 29.05.2020
comment
Процессор аннотаций сгенерирует некоторые исходные файлы, которые позже будут использоваться приложением. Я спрашивал также где-то еще, и у меня есть несколько многообещающих зацепок. Оказывается, моя проблема была с configuration, а не с execution. Я опубликую решение, как только закончу его реализацию. Между тем, если у вас есть решение, пожалуйста, опубликуйте его. Спасибо   -  person AouledIssa    schedule 01.06.2020
comment
Можете ли вы уточнить, какую версию Gradle вы используете?   -  person sonique    schedule 07.06.2020

Ответы (1)


arrow_upward
4
arrow_downward

После глубокого изучения этой темы, долгих часов чтения и множества чашек чая и кофе я обнаружил, что настройка моего проекта была не совсем правильной, и я понял, что плагин Kotlin для Android имеет свой печальный и сомнительный факт, который я надеюсь, я смогу прояснить этот самый ответ, так что возьмите чашку чая/кофе и наслаждайтесь чтением.

  1. Есть ли способ дважды запустить компиляцию kotlin? Краткий ответ на это: НЕТ!, это просто связано с тем, что gradle сам имеет ациклический граф зависимостей, что означает, что не должно быть никакого способа иметь >круговая зависимость, поэтому задача будет запускаться только один раз за gradle вызов.
  2. Как мы можем решить это ограничение? Есть два варианта: либо добавить новый Source set (для андроида это будет через добавление нового buildType), либо просто сломать чудеса дилеммы курица/яйцо и использовать артефакты.

Я много экспериментировал со всеми возможными решениями, но все же что-то пахло рыбой. Прежде всего, здесь ветка, в которой я спросил gradle пользователей о своей проблеме. Несмотря на то, что это не решило мою проблему, оно все же пролило некоторый свет на корни самой проблемы, дилемму курица/яйцо.

Пытаясь прояснить мою проблему, я продолжил свои исследования и спросил разработчиков kotlin о том, как это сделать с помощью плагина kotlin gradle. Ответы можно найти здесь

Краткая история: Невозможно напрямую расширить задачу kotlinCompile gradle просто потому, что есть «код вокруг», который инициирует компиляцию. Я имею в виду, конечно, но почему это было очень плохо спроектировано таким образом? Почему такому прекрасному языку, как kotlin, пришлось торопиться с созданием этого конкретного предположительно мощного плагина, и в основном почему его исходные коды никогда не обновлялись и не пересматривались с тех пор?

Обойти это можно с помощью их дескриптора KotlinCompilation точка входа. Лично мне это решение не нравится, так как оно ограничивает уровень гибкости, а также еще больше абстрагирует задачу компиляции.

Еще одним многообещающим способом использования gradle был artifacts, когда модуль собирает сам себя и создает артефакт (в нашем случае обычно банку), который будет использоваться другими проектами. Это звучит круто, верно? К сожалению, нет возможности добавить эту библиотеку в путь к классам consumers, и компиляция просто завершится ошибкой.

Это были мои выводы, пожалуйста, не стесняйтесь обновлять мои знания или исправлять меня, если я что-то неправильно понимаю.

Удачного кодирования!

person AouledIssa    schedule 08.06.2020