Любой способ включить подпроект buildSrc в путь к классу buildSrc корневого проекта? - PullRequest
0 голосов
/ 10 марта 2019

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

Проекты в ссылках:

До сих пор я уже перенес практически весь 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, но с различными строкамизависимости, определяемые константами (например, версиями зависимостей, группами и т.или сценарий сборки SpongeAPI не может быть скомпилирован, потому что SpongeAPI / buildSrc больше не находится в своем пути к классам.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...