Обработка отсутствующей конфигурации в зависимости от Gradle build

У меня есть сборка Gradle, которая создает основной артефакт доставки (установщик) моего продукта. Проект Gradle, который моделирует это, имеет несколько разных зависимостей в разных конфигурациях. Многие из этих зависимостей находятся в конфигурации внешних модулей по умолчанию, а некоторые из этих модулей имеют конфигурацию testResults, которая содержит результаты (zipped) тестовой задачи.

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

Я попытался сделать это, итерации по всем конфигурациям сборки продукта, итерации по зависимостям в каждой и добавление программно созданной зависимости (в новой конфигурации, созданной для этой цели) в конфигурации testResults модуля.

Другими словами, я создаю зависимости вроде:

Это заполняет эту конфигурацию просто отлично, но, конечно, когда я пытаюсь что-либо сделать с ней, она не работает в первый раз, когда я сталкиваюсь с зависимостью от модуля, который на самом деле не имеет a testResults конфигурация:

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

Как я могу гарантировать, что такие ожидаемые недостающие конфигурации не нарушают мою сборку? Я думал, что что-то делать с мягкими конфигурациями может быть ответом, но я даже не зашел так далеко (мне нужно сначала получить ResolvedConfiguration, насколько я могу судить). В качестве альтернативы, если способ, которым я это делаю, сумасшедший, что более естественная идиома Gradle для достижения этого?

Ответы

Ответ 1

Вам нужно будет проверить наличие конфигурации, прежде чем ссылаться на нее. В таких случаях gradle документация DSL является вашим другом. Фактически, проект gradle является одним из самых хорошо документированных проектов с открытым исходным кодом, с которыми я когда-либо работал.

Здесь вы обнаружите, что configurations - это просто контейнер объектов configuration. Это примеры ConfigurationContainer и Configuration соответственно, Зная это, все, что вам нужно сделать, это проверить, содержит ли контейнер configurations configuration с именем "testResults".

Это может быть достигнуто с помощью следующего кода:

if (configurations.find { it.name == 'testResults' }) {
    // do your stuff
}

Ответ 2

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

В этом случае вы можете отправить их в ProjectDependency, у которого есть свойство dependencyProject, которое позволит вам добраться до Project объект этой зависимости. Оттуда вы можете использовать depProject.configurations.findByName для проверки наличия конфигурации.

Что-то по строкам:

def processDependencyForTests( Dependency dependency ) {
  if( dependency instanceof ProjectDependency ) {
    ProjectDependency projDep = (ProjectDependency) dependency
    if( projDep.dependencyProject.configurations.findByName( 'testResults' ) ) {
      def testResultsDependency = [
        'group' : dependency.group,
        'name' : dependency.name,
        'version' : dependency.version,
        'configuration' : 'testResults'
      ]
      project.dependencies.add 'allTestResults', testResultsDependency
    }
  }

НТН