Code Once, Use Everywhere: Building Shared Libraries for Multiple Projects
summary
Built a shared Java library called Java lips that supports Spring Boot across multiple projects and runs in production for over three years, organized as core/spring/autoconfigure/starter modules so teams can opt into features. Uses editorconfig, Checkstyle, Error Prone, ArcUnit and Snyk scans, optional dependencies in auto-configuration, conditional beans and test/fallback beans, CI-driven patch IDs and simple changelog. Two reference projects run on every change and catch regressions; the approach reduces duplication but enforces high-quality, well-documented, minimal shared code.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 3:31When to share code
- 5:19What not to include
- 9:41Structuring shared libraries
- 13:31Module design principles
- 18:27Auto-configuration and beans
- 24:53Enforcing code quality
- 28:47Writing documentation
- 32:17Making changes and releases
- 36:58Versioning strategy
- 39:23Testing with reference projects
- 40:03Forcing vs advertising
- 42:14Key takeaways and final recommendations
related talks
45mCode Once, Use Everywhere: Building a Shared Module used by Multiple Projects
47mWhy your shared libraries are ill - and how to cure them
56mBuilding a Framework on top of Spring Boot
54mAvoiding a Shared Library Nightmare
48mJava's Hidden Gems: Tools and Libraries
30mSharing code among multiple projects: the case of internal libraries
51mReal World Lean Java Practices, Patterns, Hacks, and Workarounds
20mJava's Hidden Gems: Tools and Libraries