在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)
这将失败,因为sourceCompatibility并targetCompatibility通过定义java和java-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原则变得更加困难.我使其难以确定sourceCompatibility和targetCompatibility唯一的一次.我可以想到一些方法一次指定这些属性,但最简单的解决方案似乎是使用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)
| 归档时间: |
|
| 查看次数: |
4689 次 |
| 最近记录: |