Gradle> = 4.6: одновременное использование java-библиотеки и java-плагинов в многомодульной сборке

Question

С Gradle 4.6:

• https://docs.gradle.org/4.6/userguide/java_library_plugin.html#sec:java_library_separation
• https://docs.gradle.org/4.6/release-notes.html#compile/runtime-scope-separation-in-pom-consumption

были добавлены новые конфигурации: api (только в java-library plugin) & implementation (определяется обоими). ​​

В многомодульном проекте у меня есть несколько «базовых» модулей, которые действуют как внутренние библиотеки, и иногда необходимо передавать открытые зависимости времени компиляции через конфигурацию api.

Ранее мы применили плагин java рекурсивно:

subprojects {
    apply plugin: 'java'
}

Чтобы быть пуристом, мы можем применить плагин java-library к модулям "библиотеки" и плагин java к "конечному приложению"."modules.

Что если мы просто введем:

subprojects {
    apply plugin: 'java'
    apply plugin: 'java-library'
}

NOTE При правильной схеме именования (у нас ее нет) можно сделать выборочно:

subprojects {
    if (project.name.startsWith('lib-')) {
        apply plugin: 'java-library'
    } else {
        apply plugin: 'java'
    }
}

Answer 1

Плагин java-library "расширяет" базовый плагин java, так что вы можете просто применить плагин java-library ко всем вашим подпроектам, это автоматически применит плагин java.

КакВы упомянули, что идеальным / пуристическим способом было бы применить плагин java-library только к «библиотечным» проектам, но вы все равно можете применить этот плагин к модулям «конечного приложения», и это будет работать (конечно, в таких модулях вы бы использовали implementation конфигурация, а не api, поскольку это не имеет смысла).

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