blade-tool packages the SpringBlade microservice stack as twenty-three Maven modules

Why a platform split its core into a published artifact

blade-tool is not a SpringBlade application. It is the layer underneath one.

The README explains the split: SpringBlade adopts a front end and back end separated model with Saber on the front end, based on Vue3 and Element-Plus; the back end uses the Spring Cloud stack with its base components heavily encapsulated, and those encapsulations were opened out as a separate framework. That framework is blade-tool, and it has been pushed to Maven Central so you can depend on it directly. The stated benefit is reducing project bloat and letting the effort go into business development.

That reframes what you are adopting. You are not inheriting somebody's application structure or their domain model. You are importing a set of libraries that each own one concern.

The platform it comes from has a history the README is explicit about: nine years in production, through the Camden, Hoxton and 2025 generations of the architecture, and through fat jar, then docker, then k8s with jenkins deployment. That is a claim about the platform's stability record, not a compatibility guarantee for the library at version 5.0.0.

The audience is Java teams who have already chosen Spring Cloud and want the tenant, security and persistence plumbing assembled consistently rather than reimplemented per project.

The version floor is high: JDK 21 with Spring Boot 4.1

This is the module set for SpringBlade 5.0, and the version table is the adoption gate.

The core stack reads Java 21+, NodeJS 18+, Spring 7.0.8, Spring Boot 4.1.0, Spring Cloud 2025.1.2, Spring Cloud Alibaba 2025.1.0.0, Nacos Alibaba 3.2.2 and Mybatis Plus 3.5.17. The badges at the top of the README state the same in short form: JDK 21+, Spring Cloud 2025.1, Spring Boot 4.1.

Read that as a hard requirement rather than a suggestion. There is no compatibility matrix in the README and no older-branch guidance for teams still on Spring Boot 3.x. If your application is on an earlier Spring generation, this module set is not a drop-in and the repository does not describe a path from there.

The release history reinforces the point that 5.0 is a rebuild rather than an increment. Tag v5.0.0 is titled as the 5.0.0 release with a refactored upgrade to SpringBoot4, SpringCloud2025, JDK21 and TypeScript, dated 2026-07-13. Before it, v4.10.0 on 2026-06-29 added the TenantGuard tenant guard tool, and v4.9.0 on 2026-04-20 added a full-stack AI development skills collection and a fully automatic view serialisation mechanism.

The 4.x to 5.0 jump moved three axes at once: the Spring generation, the JDK baseline and the front end toolchain. Budget for re-testing rather than a version bump.

Five core modules and seventeen starters, mapped to concerns

The engineering structure block in the README is the best single view of what the library contains, and it is worth reading as a task list rather than a package list.

Seven core modules sit at the base. blade-core-bom is the Maven dependency management module, so it governs versions across everything else. blade-core-boot is the business package integration module, a quick start package for common functionality. blade-core-cloud is the Spring Cloud microservice encapsulation. blade-core-launch provides the core application startup functionality. blade-core-secure handles security and authentication encapsulation, JWT Token and permission control. blade-core-test wraps unit testing with tools and configuration, and blade-core-tool holds general utilities, constants and configuration.

Then the starters, one concern each: api-crypto for API encryption and decryption, cache, datascope for data permission with row-level control, develop for code generation across multiple templates, excel for import and export, i18n, loadbalancer for load balancing and canary release, log for unified logging and storage, mybatis as a MyBatis Plus enhancement, oss for object storage across cloud providers, redis, report, social for third-party OAuth2 login, swagger for auto-generated API docs, tenant for SaaS multi-tenancy, and transaction for Seata distributed transactions.

The design intent the README states is that packages divide clearly so that the division of labour between packages is unambiguous. That is a claim you can check against your own codebase: if a concern belongs to a starter, your project should not be reimplementing it.

Multi-tenancy and data scope are the two modules you would otherwise build

Two entries in that list carry more weight than the rest for a SaaS builder, and the README calls both out separately from the generic list.

Tenant support is stated in terms of effort saved: an extremely simplified encapsulation of the multi-tenant foundation, trading less code for a more extensible SaaS multi-tenant system. The v4.10.0 release note names a specific addition, the TenantGuard tenant guard tool, which suggests the module grew a distinct guard component rather than only annotation-driven filtering. The README does not document TenantGuard's API, so check the platform documentation before assuming it behaves like a simple tenant column filter.

Data scope is blade-starter-datascope, described as data permission encapsulation supporting row-level permission control. That is the piece most hand-rolled implementations get wrong: filtering rows by department or by user is not a query builder concern alone, because it has to compose with your data access layer consistently or a forgotten call leaks rows.

Alongside those, the security story is split in two and both parts are described as inspired by existing frameworks rather than being them. Multi-terminal authentication is self-developed while drawing on OAuth2, and can control token permission isolation between subsystems. The Secure module uses JWT for Token authentication and can extend to Redis for fine-grained control.

The honest reading of both sentences is that you are adopting an opinionated reimplementation. That is faster than building from zero and slower to reason about when it behaves unlike the framework it resembles.

Infrastructure choices are baked in: Nacos, Sentinel, Seata

Three external systems are named in the README as part of the design rather than as optional adapters.

Nacos is the choice for both the registry and the configuration centre, and the stated reason is two-fold: to slim the project down and to strengthen the linkage between modules.

Sentinel is integrated, described as protecting service stability across multiple dimensions including traffic control, circuit breaking and degradation, and system load.

Distributed transactions go through Seata, in blade-starter-transaction.

That set has consequences worth stating before you adopt.

The one entry that goes the other way is blade-starter-loadbalancer, which covers load balancing and canary release. If you expected canary deployment to be a property of your CI or ingress, note that here it is a library module inside the application.

None of this is a blocker, but it is a footprint. The README's deployment history, moving from fat jar through docker to k8s with jenkins, describes the platform's own progression rather than a requirement these modules impose on you.

There is no install command, and that is the correct shape

This is a Maven library, so the README documents no install command and there is nothing to download and run. It states that blade-tool has been pushed to Maven Central and can be introduced directly, which reduces project bloat and lets you focus on business development.

The dependency management module blade-core-bom is the entry point for version alignment, since a BOM exists precisely so that the versions of the twenty-odd modules agree with each other. The README does not give a Maven coordinates snippet or a repository block, so the coordinate details and whether a SpringBlade parent POM is required to activate the BOM are not spelled out in this file. The Gitee project for blade-tool is listed as the core framework project address, and the development manual wiki is the linked place for that detail.

What is verifiable from the repository itself is the module layout, which the README prints as a tree and which the top level directory listing confirms: seven blade-core directories and sixteen blade-starter directories, plus `pom.xml`, `deploy.sh` and a `doc/` directory.

blade-core-bom         -- Maven依赖管理模块
blade-core-boot        -- 业务包综合模块，集成常用功能的快速启动包
blade-core-cloud       -- Spring Cloud微服务封装模块 
blade-core-launch      -- 基础启动模块，提供应用启动的核心功能
blade-core-secure      -- 安全认证封装模块，JWT Token、权限控制等
blade-starter-datascope     -- 数据权限封装模块，支持行级权限控制
blade-starter-tenant        -- 多租户封装模块，SaaS多租户支持
blade-starter-transaction   -- 分布式事务封装模块，Seata分布式事务

The comments in that tree are the project's own descriptions of each module, reproduced as printed.

Two smaller signals about how the project is run. There is a `deploy.sh` at the root, and a `.github/` directory. Neither is described, so how releases are cut beyond the tags is not documented here.

LGPL-3.0, and an ecosystem that lives across Gitee and GitHub

Two adoption facts that are easy to skip.

The licence is LGPL-3.0, stated in the README badges and matched by the LICENSE file at the repository root. For commercial SaaS use, review the LGPL licence terms, which include conditions for distributing the library. That is the licence text itself rather than a view on your situation.

The second is distribution geography. The blade-tool core framework project address is on Gitee at gitee.com/smallc/blade-tool, while this mirror sits on GitHub at chillzhuang/blade-tool. The SpringBlade back end likewise has a Gitee address and a GitHub address listed side by side, and the front end frameworks Saber, Saber2 and Sword are all on Gitee.

Practically, that means a build pipeline which reaches only Maven Central is unaffected, since the README states the artifacts are published there. A pipeline or contributor workflow that assumes GitHub is the canonical source will find the Gitee locations listed alongside, and the front end repositories it may need to build against are Gitee-hosted.

On maintenance: the repository is not archived and the last push was on 2026-09-18, about a month after the v5.0.0 tag on 2026-07-13. The README badge reads V5.0.2, so tagged releases and the badge disagree slightly, which is normal for a badge updated outside a release but worth knowing if you pin versions from the badge.

Editorial conclusion

Adopt blade-tool if you are building a Spring Cloud application on JDK 21 with Spring Boot 4.1 and Spring Cloud 2025.1 and want multi-tenant, row-level data scope, Seata transactions and JWT security already wired rather than hand-rolled. Do not adopt it to inherit a SpringBlade application, since the README documents the modules as dependencies to add rather than a parent project to extend, and do not adopt it outside the Spring ecosystem. Verify first that your Maven coordinates resolve from central and that the Nacos and MyBatis Plus versions named in the stack table, Nacos Alibaba 3.2.2 and Mybatis Plus 3.5.17, match what you already run, because a BOM that shifts those out from under you will fail at build time.

Frequently asked questions

Official sources

1. chillzhuang/blade-tool on GitHub
2. Issues
3. License: LGPL-3.0
4. README
5. Releases