что значит "смена compile на api/implementation"

Ну в gradle есть понятие configuration, они могут плагинами создаваться или руками. По дефолту плагин Scala (наследник Java-плагина) создаёт "compile" configuration который подтягивает все транзитивные зависимости в компайл cp, но с плагином java-library есть разделение на API и implementation конфигурации, api- транзитивные, implementation - только при компиляции себя, в компиляции дочерних проектов их не видно если явно не продублировать, только в рантайме

"Compile" усиленно депрекейтят

Так получается у вас в консамере вашей либы, либа при компиляции, компилируется не полностью?

Проблема существовала и раньше, но со сменой этих configuration стала появляться заметно чаще

Consumer триггерит компиляцию зависимого проекта, а там хренакс, и не все классы иногда

Ну, я бы попробовал все добавить в api и посмотреть, исправит ли это ситуацию

Может неправильно поделили по этим группам

Ну из того, что я нагуглил про api & implementation

Это может быть причиной

походу это типо compile/runtime скоупы из мавена, так что врядли

Нет, дело в том, что runtimeClasspath и compileClasspath Gradle выдает одинаковый :(

И по большей части везде именно api

В тех проектах, которые переисполтзуются другими

короче звучит как баг где-то в интеграции зинка с градлом

Я тоже склонен так думать

А ещё легче повторить если включить цинку force (без инкремента) - казалось бы, наоборот задачу упростили

А можно ли у него дебаг мод подрубить и посмотреть, какие файлы он берет для компияции? И сравнить с теми, что ты изменил

Спасибо, интересная мысль. В целом проблема повторяется и на билде с отключенным кэшем и рераном зависимых таск, но возможно, где-то забывает инвалидироваться файл анализа

Вполне возможно, когда грейдл инвалидирует кеш результата таски, забывает где-то внутри про zinc. С разбиением на implementation/API инвалидация на стороне грейдла происходит по-другому/реже - и состояние zinc инвалидируется ещё реже