mall-tiny documents JDK 17 and ships a Dockerfile on openjdk:8

Nine tables, one module, and nothing else

mall-tiny is deliberately smaller than the rest of the mall family. The stated design decision is to keep only the tables related to permission management, nine of them, so a team can shape it freely. That choice defines what you get. Under src/main/java the code sits in modules/ums, which holds the permission module business code, and inside it the standard layering is controller, dto, mapper, model and service. Alongside that sit common/ for shared code split into api, config, domain, exception and service, then config/ for Spring Boot Java configuration, domain/ for shared wrapper objects, generator/ for the MyBatis-Plus generator, and security/ for authentication and authorization. The security package is subdivided further into annotation, aspect, component, config and util. Nothing in that structure hints at a product catalog, an order pipeline or a payment flow. If your requirement is an admin backend with users, roles, menus and permissions, this is the shape you want; if it is an e-commerce backend, the sibling mall project is the one that carries the domain modules.

The version table on master stops at Spring Boot 2.7.0

The technical selection table pins a full stack with exact versions, which is unusually useful and also the first place a mismatch appears. SpringBoot is 2.7.0, SpringSecurity 5.7.1, MyBatis 3.5.9, MyBatis-Plus 3.5.1 with MyBatis-Plus Generator at the same 3.5.1, Swagger-UI 3.0.0, Redis 5.0, Docker 18.09.0, Druid 1.2.9, Hutool 5.8.0, JWT 0.9.1 and Lombok 1.18.24. Read that table together with the notice at the top of the README: SpringBoot 3.x support with JDK 17 lives on a separate 3.x branch, and a microservices version built on Spring Cloud 2021 with Alibaba sits in mall-swarm. So master is the Java 8 line and 3.x is the Java 17 line, and there is no single checkout that gives you both. A microservice deployment belongs in the other repository entirely. The tags do not help you find your way here: the only published release is v1.0.1 from 2020-09-08, so working from master means untagged code more than five years later.

The bundled container stack runs on Java 8 and a hardcoded LAN address

Two files at the repository root are more revealing than the feature list, and both need editing before use. The Dockerfile starts from openjdk:8, copies ./mall-tiny-1.0.0-SNAPSHOT.jar into the container, exposes 8080 and starts the jar with a java -jar entrypoint. That base image is consistent with the Spring Boot 2.7.0 line on master, and it is inconsistent with the JDK 17 statement in the README, which is why the two have to be read together rather than separately. The docker-compose.yml is more immediate trouble. It declares a redis service from redis:5 with appendonly enabled, maps 6379:6379, and mounts /mydata/redis-tiny/data. The mall-tiny service depends on and links redis, maps 8080:8080, and sets spring.profiles.active=prod. Its datasource URL points at jdbc:mysql://192.168.3.105:3306/mall_tiny, a private address on somebody's network, so the compose file cannot work anywhere but that author's machine until you change it. The file also uses the top-level version: '3' key, which is the older compose format.

The image definition is four effective lines:

FROM openjdk:8
ADD ./mall-tiny-1.0.0-SNAPSHOT.jar /mall-tiny-1.0.0-SNAPSHOT.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar","/mall-tiny-1.0.0-SNAPSHOT.jar"]

And the service definition carries the settings you have to change:

ports:
  - 8080:8080
environment:
  - 'spring.profiles.active=prod'
  - 'spring.datasource.url=jdbc:mysql://192.168.3.105:3306/mall_tiny?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai&useSSL=false'
  - 'spring.redis.host=redis'

Getting it running means MySQL, Redis and one imported script

The setup path is short and does not need Docker. Install MySQL and Redis, then import the schema, which lives at sql/mall_tiny.sql, and run the main method of MallTinyApplication. That is the entire run procedure the README describes. Once it is up, the API documentation is served by Swagger-UI at http://localhost:8080/swagger-ui/, and the frontend that pairs with it is a separate repository, mall-admin-web, which the README says the backend plugs into directly. For development, three profiles exist in resources: application.yml as the common configuration, application-dev.yml for development, and application-prod.yml for production, and the compose file selects prod by passing spring.profiles.active as an environment variable. resources/mapper holds the MyBatis mapper.xml files and resources/generator.properties configures the code generator. There is no migration tool such as Flyway or Liquibase in that list, so schema changes are applied by editing the SQL script and re-importing, which is worth knowing before you put this in front of a team.

Table comments feed both the entity classes and the API docs

The code generator workflow has one instruction that matters more than the rest: write the comments on your table fields. The reason given is that the comments are what generate the field descriptions in the entity classes and in the interface documentation. That is a concrete mechanism rather than a style note. Once your tables are created and commented, you run the main method of MyBatisPlusGenerator, which produces controller, service, mapper, model and mapper.xml without any manual file creation. The generator takes console input and has two modes. Entering pms and then pms_brand generates the code for the single pms_brand table, while entering pms and then pms_* generates the whole pms module. The single-table mode is the one to reach for when you are adding a table to a module that already has hand-edited service code, because the module mode is fast enough to overwrite work you have done.

MyBatis-Plus covers single-table work, mapper.xml covers the rest

Once the code exists, the README splits development into three cases with a different tool for each. Single-table queries need no SQL at all: ServiceImpl and BaseMapper methods handle them, and the example UmsMenuServiceImpl uses save, updateById and list directly. Pagination is native to MyBatis-Plus too, so you construct a Page and call the page method with a QueryWrapper. Multi-table queries are the exception, where you hand-write the SQL in mapper.xml after declaring the method on the Mapper interface, as with getMenuList taking an @Param("adminId") Long and returning a List<UmsMenu>. So the boundary is clear: within one table you write Java, across tables you write SQL. That boundary also tells you what you inherit when you pick this scaffold, since the convenience layer is the vendor's rather than something the scaffold author built.

The API shape is a convention, not a framework feature

Endpoint shapes are fixed by project rule rather than by any Spring annotation, and they are worth copying exactly. Creating a record is POST /{controllerRouteName}/create, updating is POST /{controllerRouteName}/update/{id}, deleting is POST /{controllerRouteName}/delete/{id}, paged listing is GET /{controllerRouteName}/list, and fetching one record by id is GET /{controllerRouteName}/{id}. Note that delete is a POST even though a DELETE verb would read more naturally, and that the route name follows the controller. Authentication and authorization live in the security package with its annotation, aspect, component, config and util split, and the annotations there are what turn the route conventions into a permission system once an admin frontend is attached. Full parameter and return definitions live in the Swagger-UI page rather than in prose, so the API reference exists only once the application runs.

Editorial conclusion

mall-tiny suits a team that wants a runnable Spring Security admin backend with role and menu management already wired, and is willing to strip it down further. It does not suit a team that needs order, payment or member features, since only the permission tables are kept, or one that deploys straight from the bundled compose file. Before adopting, read the Dockerfile FROM openjdk:8 line and the 192.168.3.105 datasource URL in docker-compose.yml, and decide whether you track master or the 3.x branch.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. macrozheng/mall-tiny on GitHub
3. Project website
4. README
5. Releases