Gradle: добавить зависимость подпроекта как зависимость проекта root - PullRequest
0 голосов
/ 17 февраля 2020

Мы запускаем наши Java EE-приложения в WAS 8.5 и Gradle 5. * для их создания.

В прошлом мы упаковывали наше .war-приложение в архив .ear, который затем развертывали на наш сервер. Нам пришлось отделить наши библиотеки от наших приложений и включить их в качестве разделяемых библиотек, потому что по нашему опыту развертывание значительно замедлило и в некоторых случаях использовало всю системную память, приводя к сбою сервера.

После некоторых экспериментов мы понял, что нам не нужно извлекать зависимости в разделяемые библиотеки, потому что мы можем включить их в папку lib нашего архива .ear.

В настоящее время мы делаем это путем определения зависимостей нашего Приложение .war как compileOnly и переопределение их как earlib в проекте root (который создает архив .ear). Я ищу способ автоматизации этой процедуры.

Сценарий, который я использовал, выглядит примерно так:

project.configurations.named('deploy').getAllDependencies().withType(ProjectDependency.class).forEach({dependency ->
    project.configurations.named('earlib').getAllDependencies()
        .addAll(dependency.dependentProject.configurations.named('earlib').getAllDependencies())
})

// This loosely resembles the actual code I used. The thought process is right, it just might have a couple syntax errors.

// Obviously, I defined an `earlib` configuration in the subproject

Я попытался запустить этот код на этапе настройки, а также в doFirst{} раздел задачи ear. У них у всех были разные проблемы.

Первый не работал, потому что, похоже, что на этапе настройки, когда этот код выполнялся, зависимости еще не были настроены.

Последний не сделал не работает, потому что я не могу просто добавить зависимости во время выполнения (вспоминая, звучит нелепо, что я даже попробовал).

Мой вопрос: могу ли я найти фазу в построить жизненный цикл, где я могу найти и изменить зависимости? Есть ли другой способ решить мою проблему?

1 Ответ

1 голос
/ 18 февраля 2020

Технический ответ на ваши вопросы заключается в том, что вы можете использовать один из следующих способов:

  • A configuration.incoming.beforeResolve, чтобы сделать это в последнюю минуту, только когда действительно необходимо разрешить конфигурацию.
  • Используйте блок afterEvaluate, предполагая, что все остальные зависимости не определены в самих afterEvaluate.

Однако правильным решением будет использование зависимости механизм управления Gradle и эффективно объявлять, что ваш root проект, который строит EAR, зависит от конкретных c конфигураций подпроектов.

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

Идеи о том, как это работает в последней версии Gradle: https://docs.gradle.org/6.2/userguide/cross_project_publications.html Большинство из все объяснения должны работать с последними версиями 5.x.

...