Каков рекомендуемый способ группировать зависимости одного типа? - PullRequest
0 голосов
/ 05 марта 2020

Я бы хотел разделить зависимости в моем проекте по типу, и я собираюсь сделать это следующим образом:

// Implementation dependencies
dependencies {
    implementation("foo:bar:1") {
        because("reason 1")
    }

    implementation("foo:bar:2") {
        because("reason 2")
    }

    implementation("foo:bar:3") {
        because("reason 3")
    }
}

// Test implementation dependencies
dependencies {
    testImplementation("foo:bar:4") {
        because("reason 4")
    }

    testImplementation("foo:bar:5") {
        because("reason 5")
    }
}

Вопросы:

  1. Я могу построить проект после структурирования файла сборки таким образом, но я не вижу никакого авторитетного материала, утверждающего, что указание нескольких блоков dependencies формально поддерживается. Существует ли такой материал?

  2. Есть ли более предпочтительный способ разделения зависимостей по типу, чем этот? Желательно иметь конфигурацию зависимостей (implementation, testImplementation, et c.) Для каждого модуля, чтобы задокументировать причину включения каждого модуля, как в приведенной выше конфигурации.

1 Ответ

3 голосов
/ 05 марта 2020

Я не вижу никакого авторитетного материала, утверждающего, что указание нескольких блоков dependencies формально поддерживается. Существует ли такой материал?

Никакого материала не нужно, потому что Gradle DSL (Groovy или Kotlin) не является чем-то особенным или волшебным. Это просто сахар по сравнению с Gradle API .

Указание нескольких блоков dependencies совершенно законно. Если вы удалите сахар из Gradle DSL, то вызов нескольких блоков dependencies на самом деле просто делает:

project.getDependencies().add("implementation", "foo:bar:1")
project.getDependencies().add("testImplementation", "foo:bar:4")

Это ничем не отличается от простого вызова метода add(...) в List несколько раз.

Есть ли более предпочтительный способ разделения зависимостей по типу, чем этот?

Создать библиотеку (проект или подпроект), которая объединяет зависимости. Это легко сделать с помощью Java Библиотечного плагина . Например, для вашей тестовой библиотеки:

dependencies {
    api("foo:bar:4") {
        because("reason 4")
    }
    api("foo:bar:5") {
        because("reason 5")
    }
}

Затем просто используйте библиотеку в вашем основном проекте:

dependencies {
    testImplementation(project(":my-test-library")) {
        because("bundles test libs")
    }
}
...