Context
PR #37 introduced a Java CLI validator tool (migration-validator-1.0.0.jar) that performs deterministic, non-LLM verification of migration correctness. Currently our skill only runs mvn compile after each module, which can miss partial migrations, if the project still compiles, the gate passes even if not all code was migrated.
Proposal
Add deterministic validation as a step in the Execution Protocol, after COMPILE and before LOG. The validators would run automatically as part of the gate system no manual approval needed.
Validator → Module mapping
| Area |
Validation |
| build |
validate project-setup — pom.xml structure, Quarkus BOM, extensions, no Spring Boot starters |
| code |
validate persistence + validate services + validate rest — entity migration, DI/CDI conversion, REST endpoint mapping |
| frontend |
validate ui — template migration (Qute), static resources |
| testing |
None available yet |
| cleanup |
validate config — property migration completeness |
Open questions
- The validators were designed for a source→target (two directories) architecture. Our skill migrates in-place. Do we need to adapt the validators, or can we point both source and target arguments to the same directory at different git states?
- In spring2quarkus skill the
code module is split into persistence/service/rest phases. Running 3 validators after one module should work, but we need to verify the validators don't assume a specific execution order.
- Metadata extraction step: Some validators (persistence, rest) don't read Java files directly. Instead, they compare two YAML metadata files, one extracted from the Spring code and one from the Quarkus code. This requires running
extract metadata on the project before and after migration. Since we migrate in-place, we need to extract the Spring metadata before the module modifies the files (after that, the original code is gone). With git branches, we could extract it from main before starting the module. We need to define when and how this extraction step fits into the Execution Protocol.
Reference
Context
PR #37 introduced a Java CLI validator tool (
migration-validator-1.0.0.jar) that performs deterministic, non-LLM verification of migration correctness. Currently our skill only runsmvn compileafter each module, which can miss partial migrations, if the project still compiles, the gate passes even if not all code was migrated.Proposal
Add deterministic validation as a step in the Execution Protocol, after COMPILE and before LOG. The validators would run automatically as part of the gate system no manual approval needed.
Validator → Module mapping
validate project-setup—pom.xmlstructure, Quarkus BOM, extensions, no Spring Boot startersvalidate persistence+validate services+validate rest— entity migration, DI/CDI conversion, REST endpoint mappingvalidate ui— template migration (Qute), static resourcesvalidate config— property migration completenessOpen questions
codemodule is split into persistence/service/rest phases. Running 3 validators after one module should work, but we need to verify the validators don't assume a specific execution order.extract metadataon the project before and after migration. Since we migrate in-place, we need to extract the Spring metadata before the module modifies the files (after that, the original code is gone). With git branches, we could extract it frommainbefore starting the module. We need to define when and how this extraction step fits into the Execution Protocol.Reference
skills/spring2quarkus/validators/java/skills/spring2quarkus/validators/java/README.md