Hi all,
I would like to open a discussion about adding one or more Spring Boot
Starter modules for Fesod. This follows issue FESOD-614 (Enhancement: Add
New Module for Spring Boot Starter) and aims to lower integration friction
and encourage broader adoption.
1. Background Fesod currently requires manual configuration when being
integrated into Spring or other Java application stacks. In the broader
Java ecosystem, many libraries provide a Spring Boot Starter to:
- Offer opinionated defaults
- Enable auto-configuration
- Simplify dependency management
- Reduce boilerplate for application teams
Spring Boot (especially versions 3.x and the forthcoming 4.x line) has
become the de facto standard for rapid microservice and cloud-oriented Java
development. Providing an official starter would improve Fesod’s developer
experience and align it with expectations of modern Spring-based projects.
2. Motivation Key motivations:
- Reduce adoption cost: Today new users must discover, assemble, and
configure beans and factories manually.
- Promote best practices: We can encode recommended wiring patterns and
extension points.
- Multi-version environment: Fesod is on Java 8 today, while Spring Boot
3.x requires Java 17+. We need a strategy that lets existing Java 8 users
continue while offering first-class support for newer platforms.
- Ecosystem positioning: Having a starter makes Fesod appear mature and
integration-ready when evaluated against alternatives.
- Foundation for future extensions (e.g., Quarkus / Micronaut
integration later).
3. Goals / Intended Outcomes
- Provide at least one official starter artifact (e.g.,
fesod-spring-boot-starter).
- Auto-register core Fesod services (factories, default beans) using
Spring Boot’s auto-configuration mechanism.
- Offer sensible defaults but allow external override (typical Spring
conditional beans).
- Supply configuration properties namespace (e.g., fesod.*) with
metadata (spring-configuration-metadata.json) for IDE assistance.
- Provide compatibility guidance: which starter version aligns with
which Java / Spring Boot version.
- Update documentation site / README with integration quickstart.
- Set up tests (at minimum smoke tests) validating auto-configuration
under different Spring Boot versions.
4. Non-Goals (initial phase)
- Not rewriting core Fesod design just for Boot conventions.
- Not immediately providing deep AOT native-image optimizations (can be
a follow-on).
- Not initial Quarkus / Micronaut support (can be discussed separately
after Boot starter stabilizes).
5. Scope & Versioning Strategy (Open for Discussion) Because of Java 8
vs Java 17 divergence:
Option A: Single starter targeting Spring Boot 2.7+ (if still relevant) and
separately a new major for Boot 3+/Java 17.
Option B: Two coordinated artifacts:
- fesod-spring-boot-starter (for Boot 2.x / Java 8–11)
- fesod-spring-boot3-starter (for Boot 3+/Java 17+)
Initial suggestion: Adopt Option A for clarity and avoid complex shading or
multi-release maintenance. Deprecate the older line once community usage
shifts.
6. Technical Approach (Initial Thoughts)
- Use spring.factories (for Boot 2.x) and the new
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
mechanism (Boot 3.x+) appropriately.
- Provide an AutoConfiguration class that:
- Assembles default Fesod factory beans.
- Exposes configuration properties (e.g., FesodProperties) for tuning.
- Uses @Conditional* (on classpath, on missing bean) so users can
override.
- Provide a starter dependency that brings:
- fesod (and required submodules)
- Optional: fesod-extensions-* if a baseline set is recommended.
- Consider a BOM (fesod-bom) to align dependency versions and simplify
import in user projects.
- Add integration tests using Spring Boot test slices
(ApplicationContextRunner or @SpringBootTest) to verify: (a) default beans
load, (b) overrides behave, (c) properties bind.
7. Documentation Deliverables
- Quickstart: Add dependency, minimal application snippet, configuration
examples.
- Configuration reference table (property, default, description).
- Migration / compatibility matrix (Fesod version ↔ Starter version ↔
Java ↔ Spring Boot).
- Example repository (fesod-examples/spring-boot-demo).
8. Benefits / Value Proposition
- Shorter time-to-first-success for new adopters.
- Fewer support questions about basic wiring.
- Clear extension points encourage community plugins.
- Facilitates inclusion in platform stacks or internal company
archetypes.
- Creates a path later for:
- Native image enhancements (Spring AOT hints).
- Actuator integration (health indicators / metrics).
- Observability integration (Micrometer).
- Cloud deployment guides.
9. Risks / Considerations
- Added maintenance surface (keeping pace with Boot releases).
- Divergence between Java 8 baseline and modern Java features.
- Potential confusion if version mapping is unclear. Mitigation: Provide
explicit compatibility table and CI matrix.
10. Future Outlook (Beyond Phase 1)
- Add Micrometer metrics auto-configuration.
- Add health indicator (FesodHealthIndicator).
- Add Actuator endpoint for internal state or factory registrations (if
appropriate and secure).
- Explore Quarkus / Micronaut integration modules (reusing core
configuration logic).
- Evaluate AOT / native image optimizations (e.g., RuntimeHints for
Spring Boot 3+).
- Consider Gradle and Maven plugin synergy if build-time generation
becomes useful.
11. Open Questions for the Community
a. Do we agree on introducing a Spring Boot starter now?
b. Preferred versioning strategy (Option A/B/C or alternative)?
c. Minimum Spring Boot version we should target first?
d. Which Fesod components should be auto-configured by default vs opt-in?
e. Need for a BOM in the same initial effort or later?
f. Should we immediately include basic metrics / health indicators, or
defer?
12. Proposed Next Steps
- Gather feedback on this email.
- Decide on versioning approach and module naming.
- Create a design doc or wiki page summarizing agreed points.
- Set up a POC branch with initial AutoConfiguration.
- Add tests and documentation draft.
- Open a formal [VOTE] once consensus on scope and structure is clear
(if required by project policy).
If there are no strong objections, I had prepared an initial design draft
and a POC module structure for review à feat: Add New Module for Spring
Boot Starter by alaahong · Pull Request #616 · apache/fesod
<https://github.com/apache/fesod/pull/616>
Looking forward to your feedback, suggestions, and any concerns.
