依赖管理
依赖管理
版本管理
自2.1.1版本开始,blade转由gradle进行构建(Maven版本废弃), 我们采用version catalog 的方式来进行版本依赖管理,这样可以避免在多个地方重复定义版本号,也可以将GAV坐标隐藏,开发者只需要使用类型安全的访问器来定义依赖引入即可,不需要关心任何依赖的坐标和版本,鉴于此,这在重构上会非常有帮助,能够给予供需方有自由的替换时间。
有关版本管理的详细信息,请参阅Gradle版本管理。
版本定义文件: libs.versions.toml
版本目录优势
blade-catalog模块利用Gradle的Version Catalog功能,在gradle/libs.versions.toml文件中集中管理所有依赖的版本号,带来了诸多优势:
统一依赖版本
通过将所有依赖版本集中管理,确保了项目内所有模块使用完全一致的依赖版本。这避免了因不同模块引用同一依赖的不同版本而导致的冲突和不一致问题。
简化依赖声明
在模块的build.gradle.kts文件中,可以使用简洁的别名来声明依赖,而不是冗长的坐标和版本号。例如:
dependencies {
api(libs.blade.core)
implementation(libs.spring.boot.starter.web)
}易于版本升级
当需要升级某个依赖的版本时,只需在libs.versions.toml文件中修改一次,所有引用该依赖的模块都会自动使用新版本,大大简化了版本升级的流程。
提高可维护性
版本目录提供了一个清晰的视图,展示了项目使用的所有第三方依赖及其版本,便于审计和管理。
版本信息自动生成功能
项目通过KSP(Kotlin Symbol Processing)技术实现了模块版本信息的自动生成,这是一个创新的设计。
自动化版本信息生成
blade-base/blade-ksp模块中的BladeVersionProcessorProvider是一个KSP处理器,它在编译时自动生成版本信息类。当构建项目时,该处理器会创建一个实现了VersionInfo接口的对象,并自动添加@FrameworkModule和@VersionMarked注解。
版本信息的运行时扫描
blade-versions-report-spring-boot-starter模块利用Spring的ClassPathScanningCandidateComponentProvider,在应用启动时扫描所有带有@FrameworkModule和@VersionMarked注解的类。通过反射获取这些类的实例,收集所有模块的版本信息,实现了版本报告功能。这种设计使得系统能够动态地了解自身所有组件的版本状态,对于运维和故障排查非常有价值。
引入方式:
手动方式
在位于跟项目的 settings.gradle.kts 文件中引入版本定义文件并指定版本
dependencyResolutionManagement {
versionCatalogs {
create("libs") { // libs 是一个命名空间
from("team.aikero.blade:blade-catalog:latestVersion")
}
}
}插件方式
在位于跟项目的 settings.gradle.kts 文件中引入插件并指定版本
plugins {
id("team.aikero.blade.gradle.plugin.version-catalog") version ("0.1.2")
}
# 指定framework版本
versionCatalogConf {
artifactVersion = #「framework版本」
}使用
gradle可以使用原生方式与版本管理方式引入依赖
- 版本安全访问器(推荐)
声明依赖的方式: implementation(libs.blade.core)
详细使用见: 项目里引入版本管理
- 原生方式
implementation("org.springframework:spring")统一父工程
Gradle
Gradle更侧重于组合的概念,所以没有明显父子继承,很多内容都是通过组合与插件的方式,相关的一些公共的配置,抽取为插件提供使用,若不使用,则可以自行配置。
目前可用的插件可查看: plugin.md
