ContiNew Admin: two version lines, one Spring Boot admin shell

Two version lines: the admin shell and the Starter

ContiNew Admin ships as one repository but tracks two independent version numbers, and that split explains most of what the project is. The README badge reads SNAPSHOT-v4.2.0 for the framework itself, while the ContiNew Starter badge reads 2.17.0-SNAPSHOT. Those are not the same product moving at different speeds. They are different artifacts, and since version v2.1.0 the maintainers describe the backend base components and framework integration as extracted into ContiNew Starter. That library is published to the Maven Central repository under the top.continew namespace. The release counts reflect the split: the README states ContiNew Admin has shipped 25 versions and ContiNew Starter 43.

The practical consequence is that you can take the plumbing without the admin shell. If you already have a Spring Boot web application and want the date and enum parameter conversion, default thread pool, cross-origin, encryption, masking, rate limiting, idempotency, licensing, logging, exception and response handling that the README lists under the Starter component collection, you can add the dependency to an existing project. You do not have to adopt Vue 3, Arco Design, the code generator templates or the ContiNew Admin database schema. The repository layout supports the same separation internally, with continew-common, continew-extension, continew-plugin and continew-server sitting next to each other as top-level directories.

A framework that insists on owning your whole application is a different commitment from a library you can borrow one class at a time, and this project contains both shapes.

Multi-tenancy and logical delete both land in the data model

Two of the three most recent releases changed the data model rather than the feature list. v4.0.0, tagged 2025-07-27, added multi-tenancy. v4.1.0, tagged 2025-11-17, added global logical delete and a file recycle bin. Both are cross-cutting, and in a framework of this kind cross-cutting means every table and every query.

Global logical delete looks small in a changelog and large in a migration. Once deletion is logical by default, a query path that fails to apply the deleted flag returns rows that are supposed to be gone, and the failure is silent. Lists look correct, counts look correct, and the data is only wrong for someone who knows to look. The same applies to tenant columns on a schema that predates v4.0.0. The README does not document the migration path, does not name the annotation that excludes a table, and does not say how the code generator behaves when it meets a pre-existing table. If your current codebase is on v3.x, this is the largest single cost in adopting the project, and the documentation available does not size it.

The numbering also tells you where the risk sits. A minor release can carry a schema-level change here, so a pinned version is the only thing standing between a routine upgrade and a data migration.

Six Maven modules, and a dev branch as the default

The repository root is a Maven multi-module build, and the module names are the fastest way to work out where a change would land. continew-server holds the application entry point, continew-system holds the business-facing modules a generated admin screen depends on, continew-common holds shared code, continew-extension holds third-party integration points, continew-plugin holds pluggable components, and continew-auth-refresh is isolated rather than folded into the auth code. That last split is the informative one. Token refresh touches every authenticated request, so keeping it in its own module means changing session lifetime does not mean rebuilding the whole application graph.

Alongside the Java modules sit a docker directory, a lombok.config at the root, a style directory, and the Maven wrapper files mvnw and mvnw.cmd. The root also carries CHANGELOG.md, CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md, CLA.md and CLAUDE.md, and a LICENSE file is present at the root, so there is no licence file to go looking for.

Note the default branch. It is dev, not main or master, and the CI badge points at a workflow file with branch=dev. Anyone who clones and builds the default branch is building unreleased snapshot code rather than the newest tag. That is a reasonable choice for a project iterating quickly, and the wrong choice for a reproducible production build unless you pin a tag.

Agent instruction files sitting beside the Maven modules

Three entries at the repository root have nothing to do with the Java or Vue build: a .agents directory, a .claude directory, and AGENTS.md, alongside CLAUDE.md. The README's second line states the position directly, telling developers to base their work on ContiNew projects so that AI coding assistants pick up the code conventions.

This deserves more attention than it first appears. In a framework whose stated origin is one maintainer's years of archiving and refining code, the convention file is the part of that archive a machine can read. A scaffolding that ships agent instructions next to its own style directory is treating code style as part of the deliverable rather than an accident of authorship. For a team that plans to let an assistant generate code inside this project, that is the difference between generated code matching the surrounding style and generated code a reviewer has to rewrite by hand.

The limitation is equally concrete. Nothing in the README says what those files contain, which tool reads them, or whether they are kept in sync with the code they describe. There are two of them at the root, AGENTS.md and CLAUDE.md, and the README does not say whether they are duplicates, supersets or deliberately different for different agents. Read them as a starting point, not as a description of how the project is structured today.

The CRUD surface is an annotation, not a base class

The CRUD layer is the part most likely to change how you write controllers, and the mechanism is a single annotation rather than a set of classes you inherit. The README's example is four lines long.

@Tag(name = "部门管理 API")
@RestController
@CrudRequestMapping(value = "/system/dept", api = {Api.TREE, Api.GET, Api.CREATE, Api.UPDATE, Api.DELETE, Api.EXPORT, Api.TREE_DICT})
public class DeptController extends BaseController<DeptService, DeptResp, DeptDetailResp, DeptQuery, DeptReq> {}

The annotation takes a path and a set of Api constants. Here a department endpoint is registered as a tree listing plus get, create, update, delete, export and a tree dict listing, and the dict listing is described as serving dropdown option scenarios. The controller body is empty because the type parameters on BaseController supply the service, one response type for list queries, a second for detail queries, the query object and the request object. Five types on one superclass declaration is the whole of the wiring.

Two things follow. The API surface is opt-out rather than opt-in: the README says all APIs can be opened or extended as needed for the actual requirement, so the same annotation can produce a narrow endpoint or a wide one. And the code generator is the natural counterpart, because the README states that once the table design is done, a short configuration generates roughly 80 percent of the front and back end code including CRUD APIs, permission control, parameter validation and interface documentation, rising to about 95 percent for uncomplicated business logic. A framework that generates code against its own controller shape is coherent in a way that one generating endpoints for a foreign convention is not. The cost is that the annotation becomes load-bearing, and the README does not document how to override a single endpoint out of a set.

Getting it running: what the README does and does not tell you

The README gives no installation commands. There is no clone line, no compose file to run, no application.yml snippet and no database migration step, so this article does not invent one. What the project does say is where to go.

The README header links three things: online documentation at continew.top, a live demo at continew.top/docs/admin/guide/demo.html, and an issue discussion board at continew.top/docs/admin/issue-hub.html. The documentation link is the one to open first, because it is where the setup steps the README omits will be. The demo is the faster route to a different question, which is what the generated screens look like with data in them. The why-choose-us page referenced from the README's tip block is where the project makes its own comparison argument, in the documentation rather than in the README.

The repository gives two hints about how it expects to be built. The root carries the Maven wrapper files mvnw and mvnw.cmd, so a wrapper-based build is available, and there is a top-level docker directory, so a container path exists somewhere. Neither is documented in the README, and a directory named docker can hold anything from a single Dockerfile to a full compose stack. The front end is not in this repository. continew-admin-ui is listed as a separate project on GitHub, AtomGit and Gitee, so a full first run means two repositories and a build order, which the README does not spell out.

Version metadata that disagrees with itself

The version signals in this repository do not line up, and they disagree in the direction that makes an upgrade look easier than it is.

The repository description names the stack as Spring Boot v3.4.x with Java 17. The README badge reads Spring Boot 3.5.16 with Open JDK 17. Both cannot describe the same build. Someone planning an upgrade from Spring Boot 3.4 has no way to tell from the README whether the framework already assumes 3.5 APIs, and the description text is the copy most search results and shared links will carry forward.

The release timeline has a similar gap. The last push was on 2026-09-28 and the default branch is dev, so development is current. The most recent tagged release is v4.1.0 from 2025-11-17, and the badge advertises v4.2.0-SNAPSHOT, which means a feature set is finished on the branch and unreleased. The README states the project was created on 2022-12-08 and reached v1.0.0 on 2023-03-26, and that ContiNew Admin has published 25 versions against Starter's 43. The history is long and regular rather than sporadic. It is the distance between the last tag and the last push that you need to account for, not the length of the history.

The licence is Apache-2.0, and a LICENSE file sits at the root. What that grant covers is copyright and patent. It does not grant permission to present your own deployment under the ContiNew name, which matters more than usual for a project that runs three mirrors and a branded demo site.

The real alternative is a smaller artifact from the same author

ContiNew Admin is one answer to a question with at least two. The other is to take the ContiNew Starter artifact on its own, currently 2.17.0-SNAPSHOT under the top.continew namespace, and keep an admin interface you already own. The difference is scope. The Starter carries the Spring base configuration and the framework integrations; ContiNew Admin adds the multi-module system modules, the CRUD suite, the code generator and its front and back end templates on top. Choosing the full framework buys you a code generator whose output matches the runtime, and costs you the ability to change the front end stack. Choosing the Starter alone keeps your stack and gives up the generator.

The concrete reason to reach for the full framework is a team that has never shipped an internal admin tool and does not want to design one. The concrete reason not to is a team that already has hundreds of screens, a house component library, and a deployment pipeline that knows nothing about Arco Design. In that second case the migration is nobody's fault, but the framework is not a shortcut either.

The multi-tenant work also narrows the audience. v4.0.0 made multi-tenancy a feature rather than a plugin, which suits software products that resell the same application to many customers. A single-tenant internal tool will carry that machinery without using most of it.

Editorial conclusion

Adopt ContiNew Admin if your team is starting an internal admin tool from zero and wants a code generator, a CRUD annotation and a UI stack that agree with each other. Do not adopt it to reskin an existing large application, where the Vue 3 and Arco Design layer and the v4.0.0 tenant schema are costs with no offsetting benefit. Check three things before committing: whether the dev default branch and the v4.2.0-SNAPSHOT badge mean you are building unreleased code, whether the v4.1.0 global logical delete can be excluded for your existing tables, and whether the Spring Boot 3.4 or 3.5 discrepancy in the project metadata matches what your build actually resolves. The deciding factor is the code generator, and whether its output is something your team wants to own for the next five years.

Frequently asked questions

Official sources

1. continew-org/continew-admin on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases