Let users choose which files `XmlParser` parses as XML

Open
  • Is something wrong?
#9,287 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
tooling

Research direction

Start with XmlParser.accept(Path), ACCEPTED_FILE_EXTENSIONS, and XmlParser.Builder; the issue describes the parser API change and names plainTextMasks as a model for build tool integration. Trace how the Maven and Gradle integrations configure parsing, then check whether the Moderne CLI option is in scope. Done means users can configure additional XML file patterns and those files reach XML recipes during a real build.

Written by the indexing model from the issue text.

Description

enhancement parser xml
Problem

XmlParser.accept(Path) decides what is XML from a hard-coded set, ACCEPTED_FILE_EXTENSIONS, plus a few file names such as nuget.config. Neither XmlParser.Builder nor the build tool integrations offer a way to extend it. Any XML file with an extension outside the list is passed to the plain-text parser, so XML recipes never see it.

Every new format so far has needed its own issue and an OpenRewrite release (for example jrxml, #6512). Projects use many XML dialects with their own extensions, and the list can't keep up.

Our case: eXist-db is a native XML database, and its ecosystem uses many XML formats with their own file extensions. For example, collection configuration lives in collection.xconf files. Recipes targeting these files pass in RewriteTest, because xml(…) parses explicitly. In a real mod build / rewriteRun, though, the files come through as PlainText, and the recipes silently do nothing. Adding one extension at a time to OpenRewrite wouldn't cover them.

Proposal

  1. Parser: add an option to XmlParser.Builder that adds to the defaults rather than replacing them, for example:

    XmlParser.builder()
    .additionalFileExtensions("xconf")
    .build();

    accept would check these after the built-in set. An optional path-glob variant (additionalPathMatchers("**/*.xconf")) could also cover specific file names, as the special-casing of nuget.config does today.

  2. Build tool integrations: expose the option where the code model is built, otherwise the parser API alone can't be used. For example:

    • rewrite-maven-plugin: <xmlMasks> / -Drewrite.xmlMasks=**/*.xconf, mirroring the existing plainTextMasks
    • rewrite-gradle-plugin: rewrite { xmlMasks = ["**/*.xconf"] }
    • Moderne CLI: the equivalent mod build option or config entry

    Masks would make XML consistent with how plainTextMasks already lets users pull files into plain-text parsing.

Alternatives considered
  • Adding each extension to ACCEPTED_FILE_EXTENSIONS. This works case by case but doesn't scale, and every project with custom formats has to wait for an OpenRewrite release.
  • Copying or renaming files to .xml before building the code model. This needs a script outside OpenRewrite in every user's repository. Diffs and data tables then show the wrong path, and it's impossible on the Moderne platform, where users don't control the build step.
  • Re-parsing the PlainText as XML inside a recipe. This works as a bridge, but every recipe author has to do it again, and search markers have to be translated back.
Happy to contribute

We can open a PR for the XmlParser.Builder part if the API shape works for you.

Dominant language
Java
Stars
3.9k
Forks
599
Avg merge
9h 38m
Merged PRs (30d)
557

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openrewrite/rewrite

All issues in openrewrite/rewrite

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.