该文原文出处为 https://docs.spring.io/spring-boot/docs/2.0.0.M2/gradle-plugin//reference/pdf/spring-boot-gradle-plugin-reference.pdf
原题为 Spring Boot Gradle Plugin Reference Guide
作者是 Andy Wilkinson
本文为译文,若有侵权,联系删除
-----------------------------------------------------------------------------------------------------------------------
目录
1.简介
2.开始
3.管理依赖
3.1. 自定义托管版本
3.2. 了解更多
4.打包可执行文件
4.1.打包可执行jar
4.2.打包可执行war
4.2.1.配置可执行和可部署的war
4.3.打包可执行和普通文件
4.4.配置可执行文件打包
4.4.1.配置主类
4.4.2.排除Devtools
4.4.3.配置需要拆包的库
4.4.4.使文档完全可执行
4.4.5.使用PropertiesLauncher
5.发布您的应用程序
5.1.使用maven插件进行发布
5.2.使用maven-publish插件进行发布
5.3.使用应用程序插件分发
6.使用Gradle运行应用程序
6.1.重新加载资源
7.鱼执行器继承
7.1.生成构建信息
8.其他插件的反应
8.1.Java插件的反应
8.2.war插件的反应
8.3.依赖管理插件的反应
8.4.应用插件的反应
8.5.Maven插件的反应
---------------------------------------------------------------------------------------------------------------------------
1. 简介
Spring Boot Gradle插件在Gradle中提供Spring Boot支持,允许您打包可执行的jar或war文件,运行Spring Boot应用程序,并使用spring-boot-dependencies提供的依赖管理。Spring Boot的Gradle插件需要3.4或更高版本的Gradle
除了此用户指南,还提供了API文档。
2.开始
想要开始插件,首先需要把下面的代码加入你的程序中
buildscript {
repositories {
maven { url 'https://repo.spring.io/libs-milestone' }
}
dependencies {
classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.0.0.M2'
}
}
apply plugin: 'org.springframework.boot'
在独立应用中,插件对程序的改变是很少的。相反,插件会检测其他特定的插件何时被应用,并作出相应的反应。举例来说,当java插件被应用到构建可执行的jar包任务时会被自动装配。
一个典型的Spring Boot项目至少会应用到 groovy、java或者org.jetbrains.kotlin.jvm插件和io.spring.dependency-management插件,例如:
apply plugin: 'java'
apply plugin: 'io.spring.dependency-management'
想要学习更多有关于“当有其他插件被应用时,Spring Boot插件将有什么反应”,请参考第八章。
3. 管理依赖
当你应用io.spring.dependecy-management插件时,Spring boot的插件会自动从你正在应用的Spring boot版本导入spring-boot-dependencies bom。这提供了一种在Maven用户中很受欢迎的依赖管理体验。举例来说,它允许你声明在bom中管理的依赖时忽略版本号。要使用这个功能,只需要以通常的方法来声明依赖关系,但可以忽略版本号。
dependencies {
compile 'org.springframework.boot:spring-boot-starter-web'
compile 'org.springframework.boot:spring-boot-starter-data-jpa'
}
3.1 定制管理版本
当依赖管理插件管理插件时,spring-boot-dependencies bom会自动导入,且使用属性来控制其管理的依赖关系的版本。请参阅bom以获取这些属性的完整列表。
要自定义管理版本,请设置相关的属性。例如,要自定义SLF4J的版本,则由slf4j.version属性来控制
ext['slf4j.version'] = '1.7.20'
注意: 每个Spring Boot版本都是针对一组特定的第三方依赖关系设计和测试的。重写版本可能会导致兼容性问题,请谨慎处理。
3.2 了解更多
要了解更多有关依赖管理插件功能的信息,请参阅文档
4.打包可执行文件
插件可以创建包含了应用中所有依赖的可执行文件(jar文件和war文件),之后使用“java-jar”运行。
4.1.打包可执行jar
可使用bootJar来创建可执行jar包。当java插件被应用并且是BootJar的实例时任务会被自动创建。装配任务自动配置去越剧BootJar任务,因此运行组装(或构建)也将运行bootJar任务。
4.2.打包可执行war
可使用bootWar来创建可执行war包。当java插件被应用并且是BootWar的实例时任务会被自动创建。装配任务自动配置去越剧BootWar任务,因此运行组装(或构建)也将运行bootWar任务。
4.2.1.配置可执行和可部署的war
一个war文件可以被打包,使其可以使用java-jar来运行并部署到外部容器。所以,应将嵌入式servlet容器依赖添加到providedRuntime配置中,例如:
dependencies {
compile 'org.springframework.boot:spring-boot-starter-web'
providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
}
这确保了它们被打包在war文件的WEB-INF/lib-provided路径中,就不会和外部容器的类产生冲突了。
注意:providedRuntime优于Gradle的compileOnly配置,除了其他限制之外,compileOnly属性不在测试路径上,所以任何基于web的继承测试都将失败。
4.3.打包可执行和普通文件
默认情况下,当配置bootJar或bootWar任务时,jar或war任务会被禁用。可以通过启用jar或war任务将一个项目同事构建为可执行文件和普通文件。
jar {
enabled = true
}
为了避免将可执行文件和普通文件写入同一位置,将其中一个或另一个配置为使用不同的地址。一种可行的办法是配置分类器。
bootJar {
classifier = 'boot'
}
4.4.配置可执行文件打包
BootJar和BootWar任务分别是Gradle的jar和war任务的子类。因此,所有在打包jar或war可用的标准配置在打包可执行jar或war的时候都可用。还提供了一些特定于可执行jar和war的配置选择。
4.4.1.配置主类
默认情况下,通过在任务的classpath目录上寻找具有 public static void main(String[])方法的类来自动配置可执行文件的主类。
主类也可以使用任务的mainClass属性进行显示配置
bootJar {
mainClass = 'com.example.ExampleApplication'
}
另外,如果应用插件已经被应用,则可以使用mainClassName项目属性:
mainClassName = 'com.example.ExampleApplication'
最后,可在任务的manifest文件中配置Start-Class 属性:
bootJar {
manifest {
attributes 'Start-Class': 'com.example.ExampleApplication'
}
}
4.4.2.排除Devtools
默认情况下,Spring Boot的Devtools模块org.springframework.book:spring-boot-devtools将从可执行的jar或war中排除。如果你想在你的文件中包含Devtools,需要将excludeDevtools属性设置为false
bootWar {
excludeDevtools = false
}
4.4.3.配置需要拆包的库
当被嵌入到可执行文件中时,大多数库可以被直接使用,但某些库可能会存在问题。例如,JRuby包含了他自嵌套的jar支持,它假设jruby-complete.jar始终在文件系统上直接可用。
为了处理任何有问题的库,
4.4.4.使文档完全可执行
4.4.5.使用PropertiesLauncher