Shared Spring Boot Modules Without the Internal-Framework Trap
Shared code starts with good intentions: stop copying the same tracing setup, validation rules, or test helpers into every service. Then, six months later, you have a mystery JAR that pulls in half of Spring, overrides application beans, and requires a Slack message to configure.
The problem is not sharing code. The problem is treating a shared library as a bucket of reusable classes instead of a product with consumers, compatibility promises, and a sensible onboarding path.
In this post we'll look at:
- A module layout that keeps framework code contained — core code stays portable while Spring Boot integration stays convenient
- Starters and auto-configuration that help instead of hijack — useful defaults with clear escape hatches
- Configuration and test support as part of the public API — discoverable properties and reusable conventions
- Documentation and releases that scale to more than one project — fewer archaeology sessions and safer upgrades