Annotation-first config migrator for Apache Java frameworks

The moment someone realises they have this problem is usually when they inherit a mature Apache OFBiz, Struts, or Tiles project and spend three days just reading XML before writing a line of Java. They're not blocked by logic — they're blocked by configuration archaeology.

The gap persists because Apache projects are governed by volunteer contributors who prioritise backward compatibility above almost everything else. Ripping out XML defaults in favor of annotations would break thousands of existing deployments, so nobody in the Apache ecosystem has the organizational incentive to do it. The result is that every shop running one of these frameworks either lives with the XML or spends engineering cycles manually converting config to annotations — a process that's easy to get wrong and produces no tests to confirm you got it right.

What's actually missing is a tool that reads existing XML configuration files across the major Apache Java frameworks — tiles.xml, struts.xml, pom.xml module declarations, Shiro ini files — and generates equivalent, working Java annotation-based configuration, with a diff view so developers can verify the transformation before applying it. The 'too many technologies' complaint is real: developers tracking Java, Groovy, XML, and FTL simultaneously are context-switching in ways that slow debugging because errors surface in one layer but originate in another.

This is a business, not a feature, because migration projects recur every time a team upgrades their framework version, onboards new developers, or gets hit by a security audit requiring config review. A shop that migrated Struts 1 config to annotations last year faces the same problem again when they move to a newer version and new XML conventions appear. The cost of doing this manually is measured in senior developer days — easily $5,000–$15,000 per migration for a mid-sized project — and the risk of getting it wrong in a security-relevant config (Shiro, for example) is a production vulnerability.

What to build

Build a CLI tool that parses struts.xml, tiles.xml, and Shiro ini configuration files and outputs equivalent Java annotation configurations with a side-by-side diff and a test harness that verifies HTTP routing behavior is preserved before and after migration.

Where to start

Start with Apache Tiles specifically, because tiles.xml is a standalone configuration layer with a well-defined schema and no security implications, making it the lowest-risk migration target and easiest to make 100% correct before tackling Shiro or Struts.

The hard part

The hardest part is handling ambiguous or non-standard XML configurations in the wild — many production configs have custom extensions or partial overrides that don't map cleanly to annotations, so the tool will inevitably produce incomplete migrations for edge cases, and the first enterprise customer who hits one of those will distrust the entire output.

How it makes money

One-time purchase per project migration (priced around $500–$2,000 depending on project size measured in XML files), with an optional annual support tier for teams doing repeated migrations across versions.