Gradle java-library插件与java插件相比

Dra*_*sin 8 gradle

Java-library插件的Gradle文档中,它指出:

Java Library插件通过提供有关Java库的特定知识来扩展Java插件的功能.特别是,Java库向消费者公开API(即使用Java或Java库插件的其他项目)

这句话暗示只有要使用的java程序(库)应该使用该java-library插件; 而不应该使用的java程序(应用程序)应该使用该java插件.

在使用java-library插件之前,根build.gradle文件可能包含以下内容:

subprojects {
    apply plugin: 'java'
    sourceCompatibility '1.8'
    targetCompatibility '1.8'

    // other common java stuff
}
Run Code Online (Sandbox Code Playgroud)

但是现在在具有应用程序和库的多模块项目中,您无法将插件选择委托给子项目并具有以下根目录build.gradle:

subprojects {
    sourceCompatibility '1.8'
    targetCompatibility '1.8'

    // other common java stuff
}
Run Code Online (Sandbox Code Playgroud)

这将失败,因为sourceCompatibilitytargetCompatibility通过定义javajava-library插件.理想情况下,我想做以下事情:

subprojects {
    apply plugin: 'java-library'
    sourceCompatibility '1.8'
    targetCompatibility '1.8'

    // other common java stuff
}
Run Code Online (Sandbox Code Playgroud)

是否有任何理由强制java应用程序使用该java插件并且java库使用该java-library插件?是否有任何理由java应该使用java-library插件而不是插件?

编辑

为了进一步澄清我的问题,在摇篮样品中有一个多模块项目与java插件这里,为java-library插件这里.在java插件的示例中,root build.grade使用apply plugin: 'java'.java-library插件的root build.gradle 不使用任何插件.应用项目使用apply plugin: 'java'; 而核心和utils项目使用apply plugin: 'java-library'.

我的问题是为什么一些项目应该使用java插件而其他人使用java-library插件?它似乎使得不违反DRY原则变得更加困难.我使其难以确定sourceCompatibilitytargetCompatibility唯一的一次.我可以想到一些方法一次指定这些属性,但最简单的解决方案似乎是使用java-libraryfor all项目.

java插件用于某些子项目和java-library其他插件是否有任何好处?

Luk*_*fer 10

根据文档

[...] Java 库插件仅连接到插件才能正常运行java

因此,如果您将两个插件都应用到一个项目中,您应该不会遇到任何问题。例如,您可以java通过subprojects闭包将插件应用于每个项目,然后将java-library插件应用于需要插件附加功能的子项目(通过它们的build.gradle文件)。

请注意,您可以通过 的withPlugin方法PluginManager或 的withId方法指定插件相关的配置PluginContainer。对于这两种方法都适用:

如果插件已被应用,则执行该操作。如果稍后应用该插件,则该操作将在应用该插件后执行。如果从未应用插件,则永远不会执行该操作。

subprojects { sub ->
    sub.plugins.withId('java-library') {
        // configure sub
    }
}
Run Code Online (Sandbox Code Playgroud)