Блог

Пытаясь перенести несколько сложную настройку сборки с помощью Gradle (переход с древних версий Gradle) и желая использовать Kotlin-DSL, я столкнулся с проблемой невозможности «включить» / «скомпилировать» / «зависеть от» пути к классу buildSrc подпроекта.

Проекты, на которые ссылается:

• SpongeAPI
• SpongeCommon
• SpongeForge

На данный момент я уже перенес практически весь SpongeAPI со следующим pr:

https://github.com/SpongePowered/SpongeAPI/pull/1980/files

Способ настройки файловой структуры следующий:

 SpongeForge (root project)
| - SpongeCommon
|    | - SpongeAPI
|    |   | - build.gradle
|    |   | - gralde/
|    |   |    | - sponge.gradle
|    |   |    | - deploy.gradle
|    | - Gradle/
|    |   | - Minecraft.gradle (Defines some gradle plugin to set up Minecraft dependencies)
|    |   | - implementation.gradle (sets up SpongeForge/SpongeVanilla to depend on common)
|    | - build.gradle
| - build.gradle
  

С помощью настройки SpongeAPI с Kotlin-DSL мне удалось многое извлечь в плагин gradle, но с различными строковыми зависимостями, определяемыми константами (например, версиями зависимостей, группами и т.д.)

Проблема, с которой я столкнулся, заключается в том, что, когда я начал работать над переносом SpongeCommon, добавление buildSrc в SpongeCommon приведет к сбою компиляции плагина buildSrc в SpongeAPI или к сбою компиляции скрипта сборки в SpongeAPI, потому что SpongeAPI / buildSrc больше не находится в его пути к классу.

Один действительно глупый способ, которым я думал решить эту проблему, заключался в настройке depends on task для копирования содержимого SpongeAPI / buildSrc / src / main / kotlin в spongecommon’s / buildSrc / src / main / kotlin, но затем я сталкиваюсь с проблемой: а) дублирующие файлы, б) попытка использовать IDE для файлов buildSrc SpongeAPI не будет работать, потому что путь к классу для этого buildSrc не настроен.

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