Cenyol SpringMVC: a MyBatis Plus customisation that generates a working API

A MyBatis Plus customisation where the generator is the product

SpringMVC is described in one sentence that sets the scope: it is a project customised on top of MyBatis Plus, using the code generator that MyBatis Plus provides to produce template code quickly. The claim attached to that is a timing one. From starting the generation to running the application and calling endpoints such as /user/list and /user/get/1 takes less than five minutes.

That claim is what makes the project a starting point rather than an application, and the homepage points at mybatis.plus, which tells you where the real work lives.

The three steps the project asks for are the whole workflow. You design the database and configure the connection details. You run the code generator, which produces controller, entity, mapper and service plus implementation files for multiple tables in one go. And you run spring boot and open postman to test the endpoints.

There are two feature statements. The one that exists today is a one-click fast generation of curd template code, aimed at quickly developing native applications. The one that is planned is integration of the Ant Design admin template, so that the front end can be started as a separate application with the back end decoupled from it.

So the current state is a back end skeleton generator, and the planned work is on the interface side. The repository top level matches that description: a pom.xml, a src/ directory, a docs/ directory holding the two animated demonstrations, a .gitignore and a README.md. There are no GitHub releases, the licence is not recorded, and the last push was on 2026-09-24.

Running the generator, and the class name you type

The generator is invoked as a class with a main method, and you supply a table name when it runs.

run com.cenyol.mybatisplus.CodeGenerator.main();

Running com.cenyol.mybatisplus.CodeGenerator and then entering the table name generates the corresponding Controller, Entity, Mapper, Service and its Impl, which is the common set of template code a Spring application needs.

There is one configuration decision in the generator that changes how much you have to write afterwards. The project already has a CurdController wrapped, so when you generate you can configure that as the parent class of the generated controller. A generated controller then inherits the common curd methods directly, which removes the need to write the list, get, save, update and delete plumbing by hand for every entity.

That is the difference between a generator that emits a folder of near-duplicate code and one that emits a thin layer over an existing base class. The second is the version that makes the five minute claim believable.

The workflow is run from the IDE rather than from a build tool, and the project notes that you should change the package name to your own before running the generator, which can be done with a one-click rename in the IDE or by hand since there are not many files. The rename is a straight replacement of the base package:

com.cenyol.mybatisplus -> com.yours.domain

That ordering matters. Generating first and renaming afterwards means every generated file carries the wrong package name and has to be edited afterwards, so the instruction to do it first is a real time saver rather than a style note.

The mapper scan step, and the startup failure it prevents

There is one configuration step between generating the code and running the application, and the project warns about it explicitly because skipping it produces a startup failure that is hard to read.

After generating, you have to configure the mapper path in the common.config.MybatisPlusConfig file. The relevant annotations are the configuration class and the scan annotation:

com.cenyol.mybatisplus.common.config.MybatisPlusConfig
@MapperScan

The warning is that if you do not set this, the mapper bean cannot be injected when the application starts. That is the specific failure mode: the application starts, the mappers are not registered, and the injection fails.

It is a small detail with a disproportionate effect on a five minute setup, because the failure appears at startup rather than at generation time, and the message a developer sees is about a bean rather than about a forgotten scan path. The project does the reasonable thing by pointing at the file and the annotation.

The other setup step is the database connection. You design the data tables, then put the connection information into application.properties. The connection details are therefore configuration rather than code, which means the same generated project can point at a different database without touching the Java sources.

Taken together the sequence is: clone the repository, design the tables and configure the connection, run the generator, point the mapper scan at the right package, then start the application. Five steps, and each one is a discrete thing a person does rather than a configuration file with dozens of options.

Verifying with postman, and the two animated demonstrations

The project shows the result rather than describing it. You start the application directly from the IDE with spring boot, then call the endpoints with postman using post requests, and there are two animated demonstrations in the docs directory for exactly that.

One is named the-usage-of-code-generator.gif and covers the generator, and the other is named the-usage-of-web-service.gif and covers the requests. Both are in the docs/images directory.

Using post rather than a browser is the point of that choice. The generated endpoints are JSON APIs without any server-rendered page, so there is no UI to click through, and a postman collection is the fastest way to confirm that the generated controller, service and mapper are wired together correctly.

That verification also catches the thing the generator cannot check for you. The generator writes the code but it does not know whether the database schema and the entity class agree, and whether the mapper scan is configured correctly is a runtime property of the application rather than a property of the generated files. Calling one endpoint exercises the whole chain at once, from the request through the controller, the service, the mapper and the database, so a single successful call is a meaningful signal.

The project recommends going deeper on MyBatis Plus itself, and calls it a development tool rather than a generator to copy. That framing matters for anyone planning to extend this, because the generator is a configuration of MyBatis Plus and the parts you would want to change are MyBatis Plus features rather than code in this repository.

What this project is, and what it is not

It is worth being clear about the category, because the name and the description can both mislead.

This is not a framework and it is not a starter application with a product on top. It is a customised distribution of MyBatis Plus set up so that its code generator produces a specific shape of Spring project, one where the generated controllers extend a CurdController base class and the result is a working JSON API rather than a scaffold you have to fill in.

The value of that is real for a particular kind of work. When you need a back end with a handful of tables and a set of endpoints, the boilerplate is the same every time and it is exactly the boilerplate that generators are good at. The MyBatis Plus generator does that work, and this project is a preset for it.

It also has a clear boundary. The planned Ant Design integration and the front end/back end separation are not there yet, so what you get is a back end. And the licence is not recorded in the repository metadata, which is worth checking before you build on it, particularly for a project whose whole purpose is to be a starting point that you copy.

The five minute claim in the description is therefore a claim about the back end path only: from an empty project to a running API. The questions to ask before adopting it are whether the generated CurdController shape matches what your project needs, whether the package rename approach works in your build setup, and whether the absence of a recorded licence matters for your organisation.

Editorial conclusion

Cenyol SpringMVC suits a developer who wants a Spring JSON back end with a handful of tables and a set of endpoints without writing the plumbing for each entity, since the generated controllers inherit the common curd methods and the whole path is a documented five step sequence. It does not suit you as a front end starting point, because the Ant Design template integration is listed as a planned feature rather than an existing one, and the front end and back end are not yet separated. Before you build on it, check the licence yourself, since the repository metadata does not record one, and make sure you configure the mapper scan path after generation, because a missing scan shows up as a startup injection failure rather than as an obvious mistake.

Frequently asked questions

Official sources

1. Cenyol/SpringMVC on GitHub
2. Issues
3. Project website
4. README