Milestones¶

The project follows eight phases. Validation is the product; generated construction is an optional extension that only proceeds if Gate B passes.

Phase	Milestone	Status
0	Product definition and research	🟡 Partly done
1	Early feasibility experiments	✅ Done
2	Minimal repository and processor	✅ Done
3	Useful validation MVP	✅ Done
4	Real application pilot	✅ Done
5	Experimental validation release	🟡 In progress
6	Optional construction extension	⏸️ Parked (Gate B open)
7	Expansion and hardening	🟡 Started (1 of 7)

Phase 0: Product definition and research 🟡¶

Deliverable: research document and explicit product hypotheses.

Task	Status
Choose the Java and Spring baseline	✅ Build on Java 21, processor targets Java 17. Spring Framework 6.2 / Boot 3.5; also tried on Boot 4.1 / Framework 7
Write product hypotheses and success criteria	✅ Research
Define initial graph boundaries and support policy	✅ Graph boundaries, support matrix
Select representative applications	✅ See pilot results
Document Spring AOT behavior	❌ Research questions 1 and 6 (what AOT validates; AOT contribution vs adapter) are still open

Left: answer the Spring AOT questions; mark question 5 as answered by the Phase 1 integration spike; pin the officially supported Boot lines.

Phase 1: Early feasibility experiments ✅¶

Deliverable: separate go/no-go decisions for validation and construction.

Validation spike: the processor reported a missing binding and a constructor cycle, and showed runtime boundaries. Led to Gate A passing.
Integration spike (springgraph-spring, ConstructionRegistrar): a handwritten generated-style construction callback, registered by attaching an instance supplier to the scanned bean definition. Verified in a plain Spring context: availability, singleton identity, container-provided dependencies, @PostConstruct and @PreDestroy, BeanPostProcessor behavior, no duplicate beans, and a proxy (from a hand-rolled JDK-proxy post-processor) injected instead of the raw target. Not verified: real @Transactional/AOP auto-proxying and Spring Boot. See Spring integration. Gate B stays open because no benefit was measured.

Phase 2: Minimal repository and processor ✅¶

Deliverable: reliable source discovery.

springgraph-processor module with compiler tests (compile-testing).
Opt-in through -Aspringgraph.mode=advisory|strict; does nothing without it.
Direct stereotypes: @Component, @Service, @Repository, @Controller, @RestController.
Constructor rule: exactly one non-private constructor (Lombok-generated constructors count).
Processing rounds: candidates collected by name every round, analysis once in the final round, so types generated by other processors (Lombok, MapStruct) are visible.

Phase 3: Useful validation MVP ✅¶

Deliverable: validation that adds value without runtime changes.

Concrete and non-generic interface resolution.
Diagnostics: SG001 missing, SG003 eager constructor cycle, SG004 scope, SG005 constructor, SG006 unsupported feature, SG007 ambiguous, SG008 qualifier, SG009 configuration. SG002 is reserved. See the diagnostics reference.
Runtime boundaries declared with -Aspringgraph.runtimeBoundaries, with SG009 checks for typos (with "Did you mean"), stale and ineffective declarations.
Spring Data repositories and @Value parameters recognized and never counted as validated.
Deterministic report at META-INF/springgraph/graph.txt, and a note when less than half is validated.

Phase 4: Real application pilot ✅¶

Deliverable: evidence that adoption helps developers.

Four applications: an in-repo Boot + JPA pilot, spring-petclinic, spring-petclinic-rest, and a Maven + Lombok project.
Three classes of false positives found and fixed, each with a regression test.
Seeded mistakes caught at compile time in about 3 s, against about 11 s for a Boot context test.
Clean-compile overhead within run-to-run noise on the two small Gradle projects. On spring-petclinic-rest only annotation processing was measured (javac -proc:only, about 400 ms median difference), not the full build.

Details: pilot results.

Phase 5: Experimental validation release 🟡¶

Deliverable: a usable validation-first tool.

Task	Status
Getting-started documentation	✅ Getting started
Maven and Gradle examples	✅ Verified in fresh consumer projects
Document unsupported features	✅ Support matrix and diagnostics reference
Publish evaluation results	✅ Evaluation section of this site
Release an experimental `0.x`	🟡 `0.1.0-rc.4` on Maven Central, GitHub Packages and GitHub Releases. `0.1.0` not released yet

Left before 0.1.0:

✅ Fix the Maven Central validation failure: the groupId is now io.github.mrsluffy, a namespace Central verifies through the GitHub account (io.springgraph needed the domain springgraph.io). These coordinates are now permanent.
✅ Complete one full release run: 0.1.0-rc.3 was validated, published on Central, and released on GitHub from the draft.
Release 0.1.0.

Phase 6: Optional construction extension ⏸️¶

Deliverable: an optional, evidence-backed extension.

Not started, by design: it only proceeds if Gate B passes. Open questions: does an AOT-compatible variant need a BeanRegistrationAotProcessor, and does generated construction measurably beat Spring and Spring AOT on a realistic application.

Phase 7: Expansion and hardening 🟡¶

Deliverable: a stable release candidate for the declared subset. Driven by user demand.

Item	Status
Qualifiers and `@Primary`	✅ Merged (#9), unreleased. Also `@Fallback`, the decorator pattern, and `@Named` now reported as SG008. Checked against a real Spring context in 11 scenarios
Generic bindings	❌ Not started
Limited `@Bean` analysis	❌ Not started. Next candidate: removes most manual boundary declarations
Multi-module metadata	❌ Not started; needs a design first
Incremental-processing support	❌ Not started, never tested
Dependency explanation tools	🟡 The report shows why a candidate was chosen (`via @Primary`). New: `graph.json` and an experimental IntelliJ plugin (gutter icons, tool window, standalone analysis with the bundled `0.1.0-rc.4`), not on Marketplace yet and not tried by outside users
Wider version compatibility	❌ Two Spring lines tried; no compatibility matrix in CI

Still not validated after the qualifier work: several candidates matching one qualifier, @Priority, and candidates named by @Named or @ManagedBean.

Suggested order from here¶

Finish Phase 5: release 0.1.0.
Get one or two outside users. The plan's success criteria need evidence from people other than the maintainers.
Phase 7: limited @Bean analysis, then incremental-build behavior, then a version matrix in CI.
Revisit Gate B only with measurements on a realistic application.