Forem: Marko

Why Small, Regular Releases Matter in Open Source

Marko — Wed, 25 Mar 2026 13:34:24 +0000

When people talk about open source progress, they often focus on big features.

A major redesign.

A long-awaited capability.

A release packed with changes.

That kind of release can feel exciting.

But in practice, many open source projects become healthier not because of huge releases, but because of small, regular ones.

After working on my own tooling projects, I have started to appreciate that steady release cadence is not just a delivery habit. It is part of how trust is built around an open source project.

1. Large releases create more friction than people expect

A big release may sound productive, but it often comes with hidden cost:

more things to test
more things to explain
more chances for regressions
more complicated release notes
more uncertainty for users

When too many changes are bundled together, it becomes harder for users to understand what actually improved.

Instead of:

“Nice, I can adopt this one improvement right away”

the reaction becomes:

“This looks substantial, I will check it later”

And “later” often means never.

Smaller releases reduce that friction.

They make progress easier to consume.

2. Regular releases make a project feel alive

One of the silent questions people ask when they discover an open source project is:

“Is this actually maintained?”

They may not ask it directly, but they absolutely evaluate it.

Regular releases answer that question better than promises do.

A project with clear, incremental releases signals a few important things:

the maintainer is actively working on it
improvements are being shipped, not just discussed
bugs are getting fixed
feedback can turn into actual releases

That creates confidence.

Even if a release is not huge, it still tells users:

this project is moving.

3. Small releases improve feedback loops

This is especially important for tools, libraries, generators, and frameworks.

If you wait too long and pack many changes into one release, feedback becomes blurry.

When users react, it is harder to know what helped, what confused them, and what introduced problems.

Smaller releases make feedback much more useful.

You add one meaningful feature.

You fix one real bug.

You improve one part of the docs.

You clean up one internal area.

That gives users something concrete to evaluate.

It also gives maintainers a much cleaner path for iteration.

4. Not every valuable release needs a flashy headline

This is something I have come to appreciate more over time.

Some releases are exciting because they introduce a visible feature.

Others are valuable because they improve reliability, clarity, or maintainability.

Those quieter improvements matter a lot:

better docs
better examples
safer defaults
less fragile internal code
a bug fix that removes edge-case failures
small quality-of-life improvements for generated output or APIs

These are not always “headline features,” but they are often exactly what makes a project more usable.

A healthy open source project should not wait for a dramatic update before shipping progress.

5. Smaller scope makes release notes better too

Release notes are part of the product experience.

If a release is too broad, the notes become harder to write and harder to read.

Everything starts sounding equally important.

But when a release is focused, the value is easier to communicate:

here is the feature
here is the bug fix
here is the doc improvement
here is the internal cleanup

That kind of clarity helps both maintainers and users.

A good release note should make someone think:

“I understand what changed, and I know why it matters.”

Smaller releases make that easier.

6. Shipping regularly builds momentum

This might be the most underrated part.

Open source projects often lose energy when maintainers feel like every release has to be “big enough.”

That creates pressure.

And pressure creates delay.

But when smaller releases are acceptable, momentum becomes easier to maintain.

You do not need to wait until 12 things are finished.

You can ship 3 or 4 useful changes, document them well, and move forward.

That keeps the project active.

It keeps the feedback loop alive.

And it makes the next release easier too.

Final thought

In open source, consistency is often more valuable than size.

A project that releases useful improvements regularly tends to feel more trustworthy than one that disappears for long periods and returns with an oversized release.

Small releases are easier to understand, easier to test, easier to communicate, and easier to build on.

That is the approach I try to follow in my own work.

For example, I recently released v1.7.0 of Spring CRUD Generator. It is a focused release: better OpenAPI generation through field examples, bulk POST support, extra documentation, a bug fix around relation handling, and a small internal refactor.

That is not a huge release by design.

I would rather ship useful progress regularly than wait too long and bundle everything into something harder to maintain, explain, and trust.

If you want to take a look:

https://github.com/mzivkovicdev/spring-crud-generator

What Makes a CRUD Generator Actually Usable?

Marko — Thu, 19 Mar 2026 14:34:49 +0000

There are many code generators that can create CRUD resources from a config file.

On paper, that sounds great.

In practice, the real question is not:

“Can it generate code?”

The real question is:

“Can I actually trust the generated project enough to use it?”

That is where many generators start to fall apart.

Generating a few entities, repositories, and controllers is the easy part. The harder part is making the generated result feel reliable, understandable, and usable in a real workflow.

After working on my own Spring Boot CRUD generator, I realized that usability does not come from generation alone. It comes from all the small things around the generation that reduce friction and increase trust.

Here are a few lessons that stand out.

1. Code generation is not enough

A generator can create a lot of files and still feel incomplete.

You can generate entities, services, controllers, mappers, tests, migrations, and configuration files, and the first impression may still be:

“Okay, but will this actually work in my project?”

That hesitation is normal.

Developers do not trust generated code just because it exists. They trust it when they can see that:

the input format is clear
the output is predictable
the generated application can actually run
the project will not break because of missing setup
the API surface behaves the way they expect

A useful generator is not just a code emitter.

2. Validation matters more than people think

A spec-driven generator lives or dies by the quality of its validation.

If a spec file is invalid, users should know before generation.
If the spec is incomplete, they should know before generation.
If the target project setup is missing required dependencies, they should know before generation.

That is why dry-run validation is so valuable.

A dry run gives the user a chance to validate the spec and project setup without committing to a full generation step. It turns generation into a safer workflow:

write or update the CRUD spec
run validation
fix issues early
generate resources only when the setup is correct

That one layer of feedback makes a generator feel much more professional.

3. Dependency checks are part of usability

This is one of those features that is not flashy, but it solves a real pain.

A generator may support optional features like GraphQL, caching, OpenAPI, Docker integration, or workflow generation. But if the target project is missing required dependencies, the user often discovers that only after compilation fails.

That is a bad experience.

A dependency check in the validation step gives immediate feedback:

your spec enables X
your project is missing Y
fix that first

This is not a “marketing feature,” but it is exactly the kind of thing that makes a tool feel mature.

4. Sorting is a small feature with big practical value

If a tool generates list endpoints, sorting quickly becomes one of those things users expect by default.

Basic CRUD is rarely enough on its own.

Even a very simple generated API becomes much more useful if it supports controlled sorting like:

sort by name
sort by price
sort by releaseDate

The important part is not just adding sorting, but adding it in a controlled way.

A good generator should not blindly allow sorting by anything. It should let the user explicitly define which fields are sortable. That gives a better balance between flexibility and predictability.

For example:

sort:
  allowedFields: [name, price, releaseDate]
  defaultDirection: ASC

This kind of design keeps the spec simple while still making the generated API more realistic.

Sorting may not sound like a major release feature, but it makes generated CRUD resources feel much closer to something you would actually expose and use.

5. Documentation is not just documentation

Good documentation does more than explain features.

It answers silent questions like:

What does this tool actually generate?
How much setup is required?
What does the generated result look like?
Can I trust the output?
Is this maintained?
Is there a concrete example I can follow?

A README is not just a description. It is part of the product.

A clearer README reduces confusion, shortens onboarding time, and makes it easier for users to move from curiosity to actual usage.

That is especially important for generators, because they involve a bigger trust jump than a typical library.

With a normal library, a developer adds one dependency and tries one API.

With a generator, they are letting a tool create part of their codebase.

That requires more confidence.

6. A demo video changes how people evaluate the project

This may be the most underrated part.

Developers believe much faster when they can see the flow.

A short demo video can answer in under a minute what a long README sometimes cannot fully communicate:

here is the CRUD spec
here is the generation step
here is the generated project
here is the app running
here are the API calls working

That does two things at once:

it proves that the tool works
it makes the project feel real

For generator-style tools, that visual proof matters a lot.

People do not just want to see source code. They want to see the end-to-end path from input to working result.

In many cases, a demo video is not “extra content.”
It is part of trust-building.

7. The best improvements are often not the loudest ones

Not every useful release looks impressive in a headline.

Some improvements are exciting and obvious.
Others are quieter, but they make the product much better:

better validation
better docs
better defaults
safer generation flow
fewer compile-time surprises
more realistic generated endpoints

These things may not always look like major product announcements, but they are often what move a project from “interesting” to “actually usable.”

That distinction matters.

Because many tools can generate code.

Far fewer tools make the full workflow feel safe, clear, and dependable.

Final thought

If you are building a generator, think beyond output quantity.

Do not focus only on how many files you can generate.

Focus on things like:

how easy it is to validate input
how safe it is to run generation
how realistic the generated result is
how quickly a new user can trust what they are seeing

That is where usability really comes from.

I recently pushed a new release of my own project, Spring CRUD Generator, with exactly that mindset in mind: improving validation, adding dependency checks, introducing entity-level sorting, cleaning up the README, and adding a demo video plus the demo CRUD spec used in that video.

Repository: https://github.com/mzivkovicdev/spring-crud-generator

It is not the flashiest kind of release, but it is the kind of release that makes a tool more usable in real life.

Spring CRUD Generator v1.5.0: Better Spec Consistency, CI Integration Tests, and AI-Friendly Spec Authoring

Marko — Wed, 11 Mar 2026 15:44:14 +0000

I’ve just released Spring CRUD Generator v1.5.0.

It’s an open-source Maven plugin that generates Spring Boot CRUD code from a YAML/JSON configuration. The project can generate entities, DTOs, mappers, services, business services, controllers, Flyway migrations, Docker resources, and optional OpenAPI-related pieces.

This release is focused on three things:

better spec consistency
stronger CI verification for generated output
a smoother developer experience when writing and evolving specs

One of the more interesting improvements in this version is better GitHub Copilot support and autocomplete for project specs.

I don’t want to oversell that as “AI magic”, because that’s not what this project is about. The goal is simpler: if you’re editing a larger generator config, the experience is now more natural for AI-assisted authoring and easier to work with in day-to-day development.

What’s new in v1.5.0

1) `basePath` vs `basepath` consistency fix

There was an inconsistency between documentation and code:

documentation used basePath
code also accepted basepath

That is now cleaned up.

basePath is the documented form going forward, while basepath is still supported for backward compatibility but is now deprecated.

2) Integration tests for the generator project

This does not mean the generator now creates integration tests.

Instead, integration tests were added to the generator project itself, and they now run in GitHub CI. The purpose is to detect generated-code inconsistencies earlier when new changes are introduced.

That gives the project a more reliable feedback loop and makes future changes safer.

3) `relation.uniqueItems` support

A new field was added:

relation:
  uniqueItems: true

This can be used for generating Set-based relations for:

OneToMany
ManyToMany

This is useful when uniqueness is part of the intended model and a Set is a better fit than a List.

4) Fix for JSON collection imports in business services

There was a bug in business services when using:

JSON<List<T>>
JSON<Set<T>>

In those cases, List / Set imports are now generated correctly.

5) Better GitHub Copilot support + autocomplete

Spec authoring now works better with GitHub Copilot and autocomplete.

This is especially useful if your generator config is growing over time and you want a smoother editing experience without constantly double-checking every field manually.

6) Security policy added

The project now includes a security policy.

7) Documentation update

The documentation was updated to be more readable and easier to navigate.

Why this release matters

Most generator improvements are not flashy.

But consistency fixes, CI-backed verification, relation modeling improvements, and better tooling support are exactly the things that make a code generator easier to trust over time.

That was the main focus of v1.5.0: making the generator more predictable, safer to evolve, and more comfortable to use on real projects.

Links

GitHub repo: https://github.com/mzivkovicdev/spring-crud-generator

Release: https://github.com/mzivkovicdev/spring-crud-generator/releases/tag/v1.5.0

Demo project: https://github.com/mzivkovicdev/spring-crud-generator-demo

If you work with Spring Boot and prefer declarative project setup over repetitive CRUD boilerplate, this release may be useful.

Spring CRUD Generator — v1.4.0 Adds Soft Delete and Better Validation

Marko — Wed, 04 Mar 2026 14:43:02 +0000

I’ve just released Spring CRUD Generator v1.4.0 🎉

It’s an open-source Maven plugin that generates Spring Boot CRUD code from a YAML/JSON configuration — entities, DTOs, mappers, services, controllers, Flyway migrations, Docker resources, OpenAPI support, caching configuration, and more.

Repository: https://github.com/mzivkovicdev/spring-crud-generator

What’s new in v1.4.0

1) Stricter input spec validation (and better error reporting)

Validation is now significantly stricter, but also more helpful.

Instead of failing fast on the first invalid field, the generator now validates the entire entity and collects multiple validation errors before failing. Entities are still validated one-by-one, but you get a complete list of issues per entity, which makes fixing configuration problems much faster.

On top of that, relation validation got a major upgrade. The input spec is now validated for common (and painful) relation mistakes, such as:

invalid relation type values
relations referencing target models that don’t exist
invalid or missing join table configuration
invalid join column / inverse join column naming
missing join table for Many-to-Many
unsupported mapping combinations (e.g. orphanRemoval on Many-to-Many / Many-to-One)

It also enforces lower_snake_case naming rules for join table and join column-related names, which helps avoid broken or inconsistent schema artifacts.

2) Soft delete support

Soft delete is now available as a feature. This helps when your domain needs logical deletion (audit/history, restore flows, etc.) without physically removing records.

3) `orphanRemoval` support for relations

Relations now support an orphanRemoval parameter. In addition, validation prevents unsupported usage — specifically, orphan removal is rejected for Many-to-Many and Many-to-One relations to avoid generating invalid JPA mappings.

4) Hazelcast caching support (incl. Docker Compose)

Caching support now includes Hazelcast, along with cache configuration and Docker Compose resources to make it easier to spin up the required infrastructure.

Quick start (Maven)

If you want to try it out quickly:

<plugin>
  <groupId>dev.markozivkovic</groupId>
  <artifactId>spring-crud-generator</artifactId>
  <version>1.4.0</version>
</plugin>

(See the repo for full configuration examples and the demo project.)

Upgrade notes

If you’re upgrading from an earlier version: expect stricter validation. Specs that previously “worked by accident” may now fail with explicit, actionable errors.

The most common things to double-check are:

relation type values
target model names in relations
Many-to-Many definitions missing a join table
join table / join column naming (must be lower_snake_case)
avoiding orphanRemoval on Many-to-Many / Many-to-One

Links

Repo: https://github.com/mzivkovicdev/spring-crud-generator

If you try v1.4.0, I’d love feedback — especially on the new validation behavior and the Hazelcast setup.

Why I built a Spring CRUD Generator as a Maven plugin (not a CLI)

Marko — Fri, 27 Feb 2026 10:41:48 +0000

Most Spring Boot projects start the same way.

You define entities, then you repeat the same scaffolding:

repositories
services (and often a “business service” layer)
DTOs + mapping
controllers
validation and error handling conventions
docs (OpenAPI/Swagger)
migrations (Flyway)
Docker bits
tests + test data setup

None of that is hard. It’s just expensive in terms of time and focus—especially when you’re doing it for the 10th time.

That’s why I built Spring CRUD Generator: an open-source tool that generates a production-ready Spring Boot backend baseline from a single YAML/JSON spec—CRUD layers, optional Flyway migrations, optional OpenAPI/Swagger, optional GraphQL, optional Docker resources, optional caching, and optional tests/test data generation.

And I made it a Maven plugin on purpose.

This post is about why.

The goal: make the “baseline” reproducible

I wasn’t trying to generate “toy CRUD” code.

The goal was: generate a baseline you’d actually keep in a real project:

JPA/Hibernate entities
repositories, services, business services
transfer objects + mappers
REST controllers
optional GraphQL schemas/resolvers
optional OpenAPI/Swagger resources
optional Flyway migrations
optional Dockerfile + docker-compose
optional unit tests + test data (Instancio / Podam)
optional caching (Redis / Caffeine)
optional optimistic locking

In other words: reduce boilerplate, keep structure consistent across projects, and leave developers with more time for domain logic.

Why Maven plugin (instead of a CLI)?

A CLI is tempting. It’s easy to ship, easy to run, and it feels flexible.

But after using generators in multiple teams/projects, the same friction always shows up:

1) “Works on my machine” is real for generators too

A CLI easily becomes something that:

one person runs locally
others forget to run
CI doesn’t enforce
output drifts

When generation becomes part of the build, you remove that entire class of problems.

With a Maven plugin, generation is a first-class build step. If you can build the project, you can generate the baseline—consistently.

2) Reproducibility requires versioning the generator itself

If your generator version isn’t pinned, you eventually get:

“Which version did you run when you generated this?”

With Maven, the generator version is just a dependency coordinate.

That gives you:

repeatable outputs across machines/environments
predictable upgrades (change version, review diff)
easy CI consistency

3) It fits naturally into existing Java workflows

Spring Boot projects already live in Maven/Gradle land.
So instead of adding “yet another tool,” a Maven plugin integrates with what teams already use:

local build
CI pipeline
multi-module setups
profiles and environments

4) Generated code stays transparent and owned by the project

One of my strongest constraints was:
no runtime magic and no hidden framework layer.

The generator outputs code into your project. You can read it, modify it, debug it, and evolve it.
The plugin accelerates the start—then you keep full control.

The migration angle: why Maven is especially important

Migrations are where projects drift the fastest.

If you generate code but migrations are manual (or inconsistent), you still lose time—and you introduce risk.

That’s why the generator supports Flyway migrations based on differences between:

the current YAML/JSON spec
the previous generator state stored on disk

It maintains a state file:

.crud-generator/migration-state.json

This file allows the generator to detect schema changes and generate incremental migrations in common cases (like adding tables or adding/removing columns), without requiring you to hand-write SQL every time you tweak a model.

Important safety rule: table deletion is intentionally not generated.
If an entity disappears from the spec, the generator does not drop the table automatically. That’s a deliberate guardrail to reduce accidental data loss.

This is another reason Maven helps: state + migrations become part of the build + repo workflow, not “something someone ran locally.”

Spec-first: one file to describe your backend baseline

I wanted a single source of truth.

Instead of having your truth scattered across:

entity annotations
controller patterns
DTO mapping rules
documentation configuration
migration scripts
Docker resources

…the generator reads a spec (YAML/JSON) that describes entities, fields, relationships, constraints, and optional features.

Then it generates the baseline around that spec.

That’s the whole philosophy: make the boring parts declarative.

Why I didn’t build an IDE plugin first

IDE plugins can be great—especially for discoverability.

But they also:

couple you to an editor ecosystem
often lag behind build tool integration
don’t guarantee CI reproducibility

For me, correctness and repeatability mattered more than UI convenience.

Once generation is stable in the build pipeline, IDE tooling becomes an optional layer—not the foundation.

What I wanted to optimize for

This is what “success” looks like for this generator:

✅ You start a Spring Boot project and skip repetitive scaffolding
✅ Your project structure stays consistent across teams/projects
✅ Your generator runs the same in CI as it does locally
✅ You can upgrade generator versions intentionally
✅ You keep full control over the generated code
✅ Migrations remain safe and incremental
✅ You spend time on business logic, not boilerplate

Final thought

I didn’t choose Maven because it was trendy.
I chose it because generators are only truly valuable when they are:

reproducible
versioned
enforceable
consistent across environments

A Maven plugin turns code generation from a “tool you sometimes run” into a reliable part of your engineering workflow.

If you want to try it, repo: https://github.com/mzivkovicdev/spring-crud-generator

Spring CRUD Generator v1.3.0 Released - MariaDB support + Optional Null Exclusion in REST Responses

Marko — Tue, 24 Feb 2026 15:27:16 +0000

I’ve just released Spring CRUD Generator v1.3.0 🎉

If you haven’t seen it before, Spring CRUD Generator is an open-source Maven plugin that generates Spring Boot CRUD code from a YAML/JSON project config — including:

entities
transfer objects (DTOs)
mappers
services and business services
controllers

…and optionally:

OpenAPI/Swagger resources
GraphQL resolvers
Flyway migrations
Docker resources

The goal is simple: generate the repetitive CRUD boilerplate fast, keep the structure consistent, and let you focus on business logic.

What’s new in v1.3.0

✅ Full MariaDB support

The generator is now fully compatible with MariaDB, in addition to:

MySQL
PostgreSQL
MSSQL

This release also includes related updates for MariaDB support across the ecosystem around the generator:

Flyway scripts
Docker Compose setup
Database compatibility support in the generator and generated code

If you’re using MariaDB in your projects, you can now use the generator without workarounds.

✅ New property: `rest.response.excludeNull`

A new additional property is now available:

rest.response.excludeNull=true

When enabled, generated REST responses will exclude null fields from JSON output.

This is useful when you want:

cleaner API responses
smaller payloads
more controlled serialization behavior

It’s compatible with:

Spring Boot 3
Spring Boot 4

Why I added this

Two things kept coming up:

MariaDB support was a natural next step after MySQL/PostgreSQL/MSSQL compatibility.
In many APIs, people prefer not returning null fields in responses — so adding a generator-level switch made sense.

This release is focused on making the generated projects more practical for real-world setups.

Feedback welcome 🙌

If you try it, I’d really appreciate feedback — especially on:

MariaDB compatibility
Flyway script behavior
rest.response.excludeNull behavior in generated APIs

Also happy to discuss implementation details and tradeoffs behind the generator.

Spring Crud Generator v1.2.0 — Improved DB Compatibility, JSON Collections, and Reliable Docker Runs

Marko — Fri, 20 Feb 2026 10:32:00 +0000

v1.2.0 is all about making the generator smoother to use in real projects: more predictable migrations across databases, fewer Docker Compose surprises, and better JSON support for collection-based fields. Along the way, there’s also internal refactoring to keep the codebase easier to maintain and extend.

Highlights

✅ Better database migration compatibility

This release improves Flyway script generation so migrations behave more consistently across MySQL, MariaDB, MSSQL, and PostgreSQL. The goal here is simple: fewer “works on my DB” moments when switching environments or adding a second database target.

More robust Flyway migration output for cross-database scenarios
Improved compatibility with newer MySQL versions (> 8.4)

🧠 JSON type support — now with collections

The JSON type has been extended to better match how modern APIs model data. In addition to single-object JSON fields, you can now generate JSON columns for collections:

JSON<List<Type>>
JSON<Set<Type>>

This makes it much easier to model things like tags, attributes, nested configs, and other “structured but flexible” data without bending the domain model.

🐳 Docker Compose that behaves like you expect

If you’ve ever had your Spring Boot container start before the database is ready (and crash/retry until it is), this update fixes that at the Compose level.

Added healthchecks so the application starts only after database services are actually ready
Fixed Docker Compose configuration around exposed vs internal ports, reducing confusion and runtime issues

Fixes

Fixed Flyway scripts when using reserved SQL keywords (reserved keywords are now supported)
Fixed unique constraint naming for consistent, correct constraint generation
Updated .openapi-generator-ignore to avoid regenerating/overwriting:
- pom.xml
- README.md, Readme.md, readme.md

Internal Improvements

Refactored internal structure to improve maintainability and future extensibility
Added a project banner that prints useful runtime metadata (version + source/output paths), which helps a lot when running generator pipelines or debugging CI logs

Demo Repository

To make it easier to see the expected output and integration flow, there’s now a dedicated demo repository:

https://github.com/mzivkovicdev/spring-crud-generator-demo

If you’re upgrading from earlier versions, v1.2.0 should be a drop-in update in most setups. The main benefits will show up immediately if you target multiple DBs, rely on JSON-mapped fields, or run everything through Docker Compose.
Repo: https://github.com/mzivkovicdev/spring-crud-generator

Spring Crud Generator v1.2.0 — Improved DB Compatibility, JSON Collections, and More Reliable Docker Runs

Marko — Thu, 19 Feb 2026 23:22:22 +0000

Highlights

✅ Better database migration compatibility

More robust Flyway migration output for cross-database scenarios
Improved compatibility with newer MySQL versions (> 8.4)

🧠 JSON type support — now with collections

The JSON type has been extended to better match how modern APIs model data. In addition to single-object JSON fields, you can now generate JSON columns for collections:

JSON<List<Type>>
JSON<Set<Type>>

This makes it much easier to model things like tags, attributes, nested configs, and other “structured but flexible” data without bending the domain model.

🐳 Docker Compose that behaves like you expect

If you’ve ever had your Spring Boot container start before the database is ready (and crash/retry until it is), this update fixes that at the Compose level.

Added healthchecks so the application starts only after database services are actually ready
Fixed Docker Compose configuration around exposed vs internal ports, reducing confusion and runtime issues

Fixes

Fixed Flyway scripts when using reserved SQL keywords (reserved keywords are now supported)
Fixed unique constraint naming for consistent, correct constraint generation
Updated .openapi-generator-ignore to avoid regenerating/overwriting:
- pom.xml
- README.md, Readme.md, readme.md

Internal Improvements

Refactored internal structure to improve maintainability and future extensibility
Added a project banner that prints useful runtime metadata (version + source/output paths), which helps a lot when running generator pipelines or debugging CI logs

Demo Repository

To make it easier to see the expected output and integration flow, there’s now a dedicated demo repository:

https://github.com/mzivkovicdev/spring-crud-generator-demo

Spring CRUD Generator now has a full Demo Project (generated from a real spec)

Marko — Wed, 18 Feb 2026 13:56:19 +0000

When you build a code generator, the hardest part isn’t shipping features — it’s earning trust.
People want to answer questions like:

“Does it actually work end-to-end?”
“Is the output consistent and buildable?”
“What does the generated code really look like?”
“Is this stable enough to try on a real project?”

That’s why I’ve added a dedicated Spring CRUD Generator Demo repository: a complete, buildable project that exists primarily to demonstrate that the generator works reliably and produces production-style output.

What is the demo project?

Spring CRUD Generator Demo is a repository that showcases the generated output of Spring CRUD Generator in a realistic setup. It’s meant to be a reference output you can inspect anytime:

browse the package structure and layering
review generated DTOs, validation, mapping, services, controllers
see how migrations/resources/tests/docker artifacts look in a real repo
confirm the project builds like a normal Spring Boot application

In short: it’s a “proof by example” repository.

The spec used to generate the demo

The demo project is generated from the full example CRUD spec from the main generator repository.

That means the demo isn’t a cherry-picked minimal case — it’s generated from a spec that enables a broad set of features and produces a meaningful codebase.

What’s enabled in the demo (all features ON)

The demo is built to be feature-rich. The idea is to show a “full stack” backend baseline generated from configuration, including:

Database: PostgreSQL
Java: 21
Spring Boot: 4.x
Optimistic locking: enabled (with retry/backoff config)
Docker: Dockerfile + docker-compose (app + db)
Caching: Redis with expiration
OpenAPI: API spec + generated resources
GraphQL: enabled (with scalar config)
Error responses: simple format
Migrations: enabled
Tests: unit tests + test data generation (Instancio)
Additional properties: REST base path /api/v1, OSIV disabled, etc.

Here’s the exact feature snapshot (as used in the config/spec context):

database: postgresql
javaVersion: 21
springBootVersion: 4
optimisticLocking: true
docker:
  dockerfile: true
  dockerCompose: true
  app:
    image: eclipse-temurin
    port: 8080
  db:
    image: postgres
    port: 5432
    tag: latest
cache: 
  enabled: true
  type: REDIS
  expiration: 5
openApi:
  apiSpec: true
  generateResources: true
graphql:
  enabled: true
  scalarConfig: true
errorResponse: simple
migrationScripts: true
tests:
  unit: true
  dataGenerator: instancio
additionalProperties:
  rest.basePath: /api/v1
  optimisticLocking.retry.config: true
  optimisticLocking.retry.maxAttempts: 5
  optimisticLocking.backoff.delayMs: 100
  optimisticLocking.backoff.multiplier: 2.0
  optimisticLocking.backoff.maxDelayMs: 1000
  spring.jpa.open-in-view: false

Why a demo repo matters (especially for generators)

Docs and screenshots help, but they don’t replace a real codebase you can:

clone
build
run
inspect
compare across versions

A demo repository gives you a stable baseline to evaluate the generator’s output quality and consistency. It also makes regression spotting easier: as the generator evolves, you can re-generate and quickly see what changed.

If you’re considering trying Spring CRUD Generator, this demo repo is the fastest way to answer:
“Is this what I want my project skeleton to look like?”

Links (copy/paste)

Spring CRUD Generator (main repo):
https://github.com/mzivkovicdev/spring-crud-generator

Spring CRUD Generator Demo:
https://github.com/mzivkovicdev/spring-crud-generator-demo

Spec used to generate the demo (full example):
https://github.com/mzivkovicdev/spring-crud-generator/blob/master/docs/examples/crud-spec-full.yaml

Feedback welcome

If you spot something you’d like to see improved in the generated output (structure, conventions, defaults, feature toggles), open an issue or start a discussion in the main repo. The whole point of publishing a demo project is transparency — and making it easier to iterate based on real feedback.

Spring CRUD Generator v1.1.0: Field Validation, Better Redis Caching & Spring Boot 3/4 Compatibility

Marko — Tue, 10 Feb 2026 14:10:29 +0000

I just released Spring CRUD Generator v1.1.0

This version introduces field-level validation, improves Redis caching, and fixes compatibility issues so the generator now works reliably with Spring Boot 3 and Spring Boot 4. It also improves behavior when Open Session In View (OSIV) is disabled by adding EntityGraph support in generated resources.

Repository: https://github.com/mzivkovicdev/spring-crud-generator

What’s new in v1.1.0

Field validation (`fields.validation`)

You can now configure validation rules directly in entity fields using a new optional validation section (required/not-null, length/range constraints, patterns, and collection size limits).

Regex validation is supported via pattern.

Cache & Redis improvements

Fixed generation of @Cacheable(value=...) values.
Added HibernateLazyNullModule to improve Redis caching behavior with Hibernate lazy-loaded entities.

Spring Boot 3 & 4 compatibility

Resolved compatibility issues — the generator is now fully compatible with Spring Boot 3 and Spring Boot 4.

OSIV control + EntityGraph support

New configuration entry: additionalProperties.spring.jpa.open-in-view (default: false).
When OSIV is disabled (recommended), generated resources use EntityGraph to handle lazy relations safely.

Improvements & stability

Documentation and tests updated for the new validation model.
Refactored generator internals for readability and maintainability.
Fixed an NPE edge case when min/max validation values are not provided.

Updated CRUD spec YAML (short example)

The project includes an updated full CRUD spec YAML reference example. Below is a shortened version that highlights the new and most important parts (validation + OSIV):

configuration:
  database: postgresql
  javaVersion: 21
  springBootVersion: 4
  cache:
    enabled: true
    type: REDIS
    expiration: 5
  openApi:
    apiSpec: true
  additionalProperties:
    rest.basePath: /api/v1
    spring.jpa.open-in-view: false
entities:
  - name: ProductModel
    storageName: product_table
    fields:
      - name: id
        type: Long
        id:
          strategy: IDENTITY
      - name: name
        type: String
        column:
          nullable: false
          unique: true
          length: 10000
        validation:
          required: true
          notBlank: true
          minLength: 10
          maxLength: 10000
      - name: price
        type: Integer
        column:
          nullable: false
        validation:
          required: true
          min: 1
          max: 100
      - name: users
        type: UserEntity
        relation:
          type: OneToMany
          fetch: LAZY
          joinColumn: product_id
        validation:
          required: true
          minItems: 1
          maxItems: 10
  - name: UserEntity
    storageName: user_table
    fields:
      - name: id
        type: Long
        id:
          strategy: IDENTITY
      - name: email
        type: String
        validation:
          required: true
          email: true
      - name: password
        type: String
        validation:
          required: true
          pattern: "^(?=.*[A-Za-z])(?=.*\\d)[A-Za-z\\d]{8,}$"

Upgrade notes

fields.validation is optional — add it only where needed.
spring.jpa.open-in-view defaults to false. If your project relies on OSIV behavior, explicitly set it to true.

If you find this project useful, I’d really appreciate a star on the repo — it helps a lot and keeps the momentum going.

Development continues, and more improvements are on the way. Thanks for the support!

Spring CRUD Generator: a YAML/JSON-driven Spring Boot backend generator (version update + stability improvements)

Marko — Tue, 27 Jan 2026 18:55:51 +0000

If you saw my initial post about Spring CRUD Generator v1.0.0, this is a follow-up with a version update and a more complete overview of what the project is aiming to solve.

Spring CRUD Generator is an open-source Maven plugin that generates a Spring Boot backend from a single YAML/JSON spec. The main goal is to reduce repetitive CRUD boilerplate and keep a consistent baseline across projects.

Version update: 1.0.2

Why I built this

In most Spring Boot projects, the first few hours (or days) often look the same:

CRUD layers (entity/repo/service/controller)
DTO mapping / mappers
consistent error responses
database migrations (and keeping them in sync)
Docker bits
OpenAPI and resource structures
tests and test data setup

Spring CRUD Generator tries to make that “baseline” reproducible from a spec, so you can focus on domain logic instead of wasting your time and concentration writing the same code again and again.

What it can generate

Depending on the configuration, it can generate:

CRUD stack: entities, repositories, services, mappers, REST controllers
Flyway migrations (incremental change detection)
OpenAPI specs + optional resource generation
Dockerfile + docker-compose
Unit tests + test data generation (Instancio/Podam)
Caching (Redis/Caffeine)
GraphQL

What improved since v1.0.0

The initial version proved the concept, but real usage quickly exposed edge cases. Recent releases focus on stability and correctness, especially around:

OpenAPI generation and schema handling (including optional fields)
ID naming consistency across endpoints and DTOs
improved equals/hashCode generation depending on whether the model is JSON-centric or a table entity
stricter validation so misconfigurations fail fast

Example spec (YAML)

Here is a small example showing the overall idea:

configuration:
  database: postgresql
  migrationScripts: true
  errorResponse: MINIMAL
  openApi:
    apiSpec: true
    generateResources: true
  docker:
    dockerfile: true
    dockerCompose: true
  tests:
    unit: true
    dataGenerator: instancio

entities:
  - name: Product
    storageName: product_table
    audit:
      enabled: true
      type: LocalDate
    fields:
      - name: id
        type: Long
        id:
          strategy: IDENTITY
      - name: name
        type: String
      - name: tags
        type: List<String>

Quick start

Create your spec file, for example:

src/main/resources/crud-generator.yml

Configure the Maven plugin (see the repository README)
Run generation

mvn clean install -DskipTests -Pgenerate-resources

This should generate the backend sources and related resources based on your YAML/JSON spec.

Links

Github repo:

https://github.com/mzivkovicdev/spring-crud-generator

Maven Central artifact:

dev.markozivkovic:spring-crud-generator:1.0.2

Feedback welcome

If you have a few minutes, I’d love feedback on:

the spec design (YAML/JSON structure and ergonomics)
what you expect from generated “production baseline” code
edge cases you’d test first

Spring CRUD Generator (v1.0.0): Generate Spring Boot CRUD, Flyway, tests & more from YAML/JSON

Marko — Fri, 23 Jan 2026 15:06:11 +0000

I just open-sourced Spring CRUD Generator (v1.0.0) — a Maven plugin that generates a production-ready Spring Boot backend from a single YAML/JSON spec.

The goal: less boilerplate, consistent structure, and faster iteration.

What it can generate (depending on configuration)

CRUD stack: entities, repositories, services, mappers, REST controllers
Flyway migrations (incremental change detection via state files)
OpenAPI specs + optional resource generation
Dockerfile + docker-compose
Unit tests + test data generation (Instancio/Podam)
Caching (Redis/Caffeine)
GraphQL

Maven coordinates

dev.markozivkovic:spring-crud-generator:1.0.0

GitHub: https://github.com/mzivkovicdev/spring-crud-generator

Tiny spec example

configuration:
  database: postgresql
  migrationScripts: true
  errorResponse: MINIMAL
  openApi:
    apiSpec: true
    generateResources: true
  docker:
    dockerfile: true
    dockerCompose: true
  tests:
    unit: true
    dataGenerator: instancio

entities:
  - name: Product
    storageName: product_table
    audit:
      enabled: true
      type: LocalDate
    fields:
      - name: id
        type: Long
        id:
          strategy: IDENTITY
      - name: name
        type: String
      - name: tags
        type: List<String>

Quick start

Add a Maven profile and run the generator goal (see README for the full setup and configuration reference).

mvn clean install -Pgenerate-resources -DskipTests

Feedback

I'd love to hear your feedback, if you have ideas for additional features or improvements, that is highly appreciated!

Forem: Marko

Why Small, Regular Releases Matter in Open Source

1. Large releases create more friction than people expect

2. Regular releases make a project feel alive

3. Small releases improve feedback loops

4. Not every valuable release needs a flashy headline

5. Smaller scope makes release notes better too

6. Shipping regularly builds momentum

Final thought

What Makes a CRUD Generator Actually Usable?

1. Code generation is not enough

2. Validation matters more than people think

3. Dependency checks are part of usability

4. Sorting is a small feature with big practical value

5. Documentation is not just documentation

6. A demo video changes how people evaluate the project

7. The best improvements are often not the loudest ones

Final thought

Spring CRUD Generator v1.5.0: Better Spec Consistency, CI Integration Tests, and AI-Friendly Spec Authoring

What’s new in v1.5.0

1) basePath vs basepath consistency fix

2) Integration tests for the generator project

3) relation.uniqueItems support

4) Fix for JSON collection imports in business services

5) Better GitHub Copilot support + autocomplete

6) Security policy added

7) Documentation update

Why this release matters

Links

Spring CRUD Generator — v1.4.0 Adds Soft Delete and Better Validation

What’s new in v1.4.0

1) Stricter input spec validation (and better error reporting)

2) Soft delete support

3) orphanRemoval support for relations

4) Hazelcast caching support (incl. Docker Compose)

Quick start (Maven)

Upgrade notes

Links

Why I built a Spring CRUD Generator as a Maven plugin (not a CLI)

The goal: make the “baseline” reproducible

Why Maven plugin (instead of a CLI)?

1) “Works on my machine” is real for generators too

2) Reproducibility requires versioning the generator itself

3) It fits naturally into existing Java workflows

4) Generated code stays transparent and owned by the project

The migration angle: why Maven is especially important

Spec-first: one file to describe your backend baseline

Why I didn’t build an IDE plugin first

What I wanted to optimize for

Final thought

Spring CRUD Generator v1.3.0 Released - MariaDB support + Optional Null Exclusion in REST Responses

What’s new in v1.3.0

✅ Full MariaDB support

✅ New property: rest.response.excludeNull

Why I added this

Links

Feedback welcome 🙌

Spring Crud Generator v1.2.0 — Improved DB Compatibility, JSON Collections, and Reliable Docker Runs

Highlights

✅ Better database migration compatibility

🧠 JSON type support — now with collections

🐳 Docker Compose that behaves like you expect

Fixes

Internal Improvements

Demo Repository

Spring Crud Generator v1.2.0 — Improved DB Compatibility, JSON Collections, and More Reliable Docker Runs

Highlights

✅ Better database migration compatibility

🧠 JSON type support — now with collections

🐳 Docker Compose that behaves like you expect

Fixes

Internal Improvements

Demo Repository

Spring CRUD Generator now has a full Demo Project (generated from a real spec)

What is the demo project?

The spec used to generate the demo

What’s enabled in the demo (all features ON)

Why a demo repo matters (especially for generators)

Links (copy/paste)

Feedback welcome

1) `basePath` vs `basepath` consistency fix

3) `relation.uniqueItems` support

3) `orphanRemoval` support for relations

✅ New property: `rest.response.excludeNull`

Field validation (`fields.validation`)