Я строю набор модулей Android с фиксированным API, который зависит от других внутренних модулей.Gradle представила здесь замечательную функцию (время сборки), позволяющую разделять зависимости от этих внутренних модулей на две категории:
api - эти модули являются «API» и транспортируют свои зависимости дальше вверх по стеку зависимостей.(например, потому что на их API также ссылаются в другом API) implementation - эти модули - чистая деталь реализации, не являются частью API реализующего модуля
Gradle использует это главным образом для ускорения сборок, потому что если зависимость реализации какого-либо модуля изменилась, его API остается постоянным, и, следовательно, зависимые модули не нужно перекомпилировать. В этом сообщении в блоге это хорошо подводится .
Теперь, когда я публикую свои модули, очевидно, что зависимости implementation и api становятся обычными зависимостями Maven в том смысле, что даже внутренние модулибудет «утекать» внутренний API в код, который реализует только внешний API.
Я знаю, что, вероятно, нет способа правильно решить эту проблему, и я предполагаю, что со временем люди разработали различные обходные пути, чтобы справиться с ситуацией,как, например, создание «толстых» библиотек, которые включают внутренние зависимости, но скрывают их через видимость пакетов или тому подобное, но это не тот путь, по которому я могу пойти - поскольку мои модули действительно являются модулями в том смысле, что они могут и должны бытьпотребляемый отдельно (и в конечном итоге объединяемый друг с другом), я не могу справиться со сложностью создания толстых библиотек, таких как "moduleA + moduleB", "moduleA + moduleC", aso.
Итак, что делают другие людиисправить эту проблему?Каковы другие полезные обходные пути?У меня такое ощущение, что отсутствует модификатор видимости для межмодульной группы, что говорит о реализации кода: «Этот класс можно использовать только в той же группе Maven, даже если он общедоступен».
Идеи