u/wimdeblauwe

Hi everyone,

I just self-published a new book called Crafting Spring Boot Starters. It's aimed at developers who want to package their own reusable functionality as a proper auto-configured starter, the way Spring Boot itself does it.

Topics covered include:

• How Spring Boot auto-configuration actually works under the hood
• Structuring and naming your own starters
• Writing @ConfigurationProperties correctly, with validation and IDE metadata
• Conditional configuration (@ConditionalOnClass, @ConditionalOnProperty, etc.)
• Testing starters with ApplicationContextRunner
• Publishing your starter so others can consume it

There's a free sample you can grab first, which includes the foreword written by Phil Webb (Spring Boot co-founder). The full book also ships with a zip of AI skills you can use to audit your own starter.

More info here: https://www.wimdeblauwe.com/books/crafting-spring-boot-starters/

If you decide to buy it, this link gives 10% off: https://leanpub.com/crafting-spring-boot-starters/c/LAUNCH10

It's fully self-published, so any feedback, questions, or upvotes are much appreciated 🙏

I kept running into the same problem on Thymeleaf projects: no real way to share reusable UI components (buttons, cards, whatever) across apps without copy-pasting HTML/CSS/JS or hand-rolling fragile th:replace fragments. No slots, no clean way to pass through arbitrary attributes (annoying if you use htmx and need hx-* on a component), no live reload for the component's own CSS/JS during development.

So I worked through building an actual Thymeleaf component library packaged as a Spring Boot starter. Auto-configured, drops into any Thymeleaf app as a dependency, with a <tcl:button>-style tag instead of fragment includes. Went from this:

<div th:replace="~{tcl/components/button :: button(label='Submit', primary='true')}"></div>

to this:

<tcl:button primary>Submit</tcl:button>

...with proper attribute passthrough and slot support so you're not limited to what the component author thought to expose. Wrote it up as a 4-part series as I went, mostly so I'd have a reference for myself next time, but figured it might help others hitting the same wall:

• Part 1 — getting the starter set up: auto-configuration, Vite for the library's CSS/JS with instant reload while you work on the library.
• Part 2 — turning a th:replace fragment into an actual <tcl:button> component with typed attributes plus passthrough for arbitrary ones (so hx-* etc. still work).
• Part 3 — adding slot support, so consumers can put arbitrary content (icons, custom markup) inside a component instead of being limited to attributes.
• Part 4 — wiring in AlpineJS for client-side interactivity, bundled cleanly inside the library itself.

Series starts here: https://wimdeblauwe.com/blog/2026/07/27/writing-a-thymeleaf-component-library

Full example code for all 4 parts: https://github.com/wimdeblauwe/blog-example-code/tree/master/thymeleaf-component-library

Curious if others building internal design systems on top of Thymeleaf have solved this differently? Did you go the same route, or land on something else (Thymeleaf dialects, a different templating layer, etc.)?

✍️ New blog post: Testing OAuth2 client login with mock-oauth2-server

If you want to test the security of your Thymeleaf application that uses OAuth2 client login (Keycloak, Okta, ...), mock-oauth2-server is a great libray for that!

The post shows how to configure Spring Boot with Thymeleaf and Keycloak for local development and continues to show how to automate testing the security setup with the mock-oauth2-server library.

https://www.wimdeblauwe.com/blog/2026/07/07/testing-oauth2-client-login-with-mock-oauth2-server/