У меня есть проект Gradle с 3 подпроектами: core
, 1_13
и 1_14
. 1_13
и 1_14
зависят от проекта core
, но окончательная сборка должна быть сделана в проекте core
, и я хотел включить сборки 1_13
и 1_14
в банку.
В подпроектах 1_13
и 1_14
есть элементы, которых нет в подпроекте core
.
На самом деле я использую sourceSets
для включения исходных файлов проектов 1_13
и 1_14
, но тот факт, что в подпроектах есть зависимости, которых нет в подпроекте core
, и что я не могу использовать apiElements
в зависимостях подпроект core
, потому что, если я делаю циклический импорт, я застреваю.
Собственно, я использую это:
sourceSets {
main {
java {
srcDirs 'src', '../1_13/src', '../1_14/src'
resources {
srcDir 'resources'
}
}
}
}
Но поскольку библиотеки отсутствуют в основных подпроектах, сборка завершается неудачно.
Я уточняю, что мне нужны библиотеки только во время компиляции, а не во время выполнения. Я также не могу добавить библиотеки в подпроект core
, потому что в подмодулях используются разные версии одной и той же библиотеки. Основной модуль предназначен только для определения того, следует ли использовать тот или иной пакет.
Самым простым способом было бы извлечь общую логику, используемую 1_13
и 1_14
, в новый проект (например, common
) и добавить 1_13
и 1_14
в качестве реальных зависимостей к основному проекту.
Конечно, вы можете взломать что-то вроде «использовать зависимости подпроектов как зависимости основного проекта», но такие хаки обычно вызывают больше проблем позже.
Ну да. Это будет лучший способ сделать это. Что именно делает эту настройку болезненной и сложной в обслуживании? У нас около 100 проектов в одном рабочем пространстве, и это работает достаточно хорошо.
@RedDev Иначе зачем вообще нужны подпроекты? Самый простой способ — переместить все в проект core
, и все готово.
Я не могу переместить все в основной проект, потому что в разных модулях я использую разные версии одной и той же библиотеки, и это не разрешено Gradle, но я нашел решение, позволяющее делать именно то, что я хочу, я добавлю ответ и отметьте как решенный! Спасибо за помощь :)
Продолжив поиски некоторое время, я нашел способ сделать именно то, что я хочу, используя задачу Gradle.
На самом деле, я создал задачу, чтобы объединить все jar-файлы разных модулей:
task buildPlugin(type: Jar, group: 'build') {
// Change the archive name and include all outputs of build of modules
archiveFileName = "${rootProject.name}.jar"
from getRootProject().allprojects.findAll().sourceSets.main.output
// Delete the old jar of the core module, to keep only the finally build jar file
doLast {
var oldJar = new File(project.buildDir, "libs/" + project.name + "-" + project.version + ".jar")
if (oldJar.exists()) {
oldJar.delete()
}
}
}
Один из способов, который я нашел для решения этой проблемы, состоял в том, чтобы создать еще один подпроект, чтобы избежать зацикливания, например
api
, который содержал только общие классы, и предоставить1_13
и1_14
фабрику (абстрагированную в API) для создания экземпляров классов API. Это позволяет избежать зацикливания депов, но гораздо более болезненно настраивать и поддерживать. (Это то, что вы сказали, как я понял)