Экспорт подпроекта Gradle в банку без добавления его в зависимости

У меня есть проект 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, потому что в подмодулях используются разные версии одной и той же библиотеки. Основной модуль предназначен только для определения того, следует ли использовать тот или иной пакет.

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
0
23
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Самым простым способом было бы извлечь общую логику, используемую 1_13 и 1_14, в новый проект (например, common) и добавить 1_13 и 1_14 в качестве реальных зависимостей к основному проекту.

Конечно, вы можете взломать что-то вроде «использовать зависимости подпроектов как зависимости основного проекта», но такие хаки обычно вызывают больше проблем позже.

Один из способов, который я нашел для решения этой проблемы, состоял в том, чтобы создать еще один подпроект, чтобы избежать зацикливания, например api, который содержал только общие классы, и предоставить 1_13 и 1_14 фабрику (абстрагированную в API) для создания экземпляров классов API. Это позволяет избежать зацикливания депов, но гораздо более болезненно настраивать и поддерживать. (Это то, что вы сказали, как я понял)

RedDev 04.04.2022 22:58

Ну да. Это будет лучший способ сделать это. Что именно делает эту настройку болезненной и сложной в обслуживании? У нас около 100 проектов в одном рабочем пространстве, и это работает достаточно хорошо.

dpr 05.04.2022 10:12

@RedDev Иначе зачем вообще нужны подпроекты? Самый простой способ — переместить все в проект core, и все готово.

dpr 05.04.2022 10:15

Я не могу переместить все в основной проект, потому что в разных модулях я использую разные версии одной и той же библиотеки, и это не разрешено Gradle, но я нашел решение, позволяющее делать именно то, что я хочу, я добавлю ответ и отметьте как решенный! Спасибо за помощь :)

RedDev 05.04.2022 19:00
Ответ принят как подходящий

Продолжив поиски некоторое время, я нашел способ сделать именно то, что я хочу, используя задачу 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()
        }
    }
}

Другие вопросы по теме