Add support for "contains" in XML XPath matching

[BrendanHart]

What version of OpenRewrite are you using?

I am using

• OpenRewrite v8.62.2 (latest in main)

What is the smallest, simplest way to reproduce the problem?

    @Test
    void searchWithContains() {
        rewriteRun(
          spec -> spec.recipe(new FindTags("/dependencies/dependency[contains(artifactId, 'abc')]")),
          xml(
            """
            <dependencies>
                <dependency>
                    <artifactId>org.openrewrite</artifactId>
                </dependency>
            </dependencies>
            """,
            """
              <dependencies>
                  <!--~~>--><dependency>
                      <artifactId>org.openrewrite</artifactId>
                  </dependency>
              </dependencies>
              """
          )
        );
    }

What did you expect to see?

Test fails since artifactId does not contain abc.

What did you see instead?

Test passes.

Are you interested in contributing a fix to OpenRewrite?

Yes

[timtebeek]

Thanks for the offer to help! Indeed for the moment we support a limited set of XPath methods, as seen here:

rewrite/rewrite-xml/src/main/java/org/openrewrite/xml/XPathMatcher.java

Lines 32 to 41 in 8ce5308

	* Supports a limited set of XPath expressions, specifically those documented on <a
	* href="https://www.w3schools.com/xml/xpath_syntax.asp">this page</a>.
	* Additionally, supports `local-name()` and `namespace-uri()` conditions, `and`/`or` operators, and chained conditions.
	* <p>
	* Used for checking whether a visitor's cursor meets a certain XPath expression.
	* <p>
	* The "current node" for XPath evaluation is always the root node of the document. As a result, '.' and '..' are not
	* recognized.
	*/
	public class XPathMatcher {

If we can safely and without a performance hit add support for contains then that could be a good addition indeed.

[BrendanHart]

@timtebeek do we feel like generally enhancing the XPath implementation might be a good idea? Right now it's heavily based on regular expressions, maybe spending the time to use ANTLR or something to parse the XPath expressions would make implementation simpler, without introducing extra dependencies since ANTLR is already being used for XML?

[timtebeek]

hi! Thanks for the suggestion; I feel @knutwannheden might best weigh in here about the relative merits and expected performance, as he's recently gone in the opposite direction for our method matchers in

• Optimize MethodMatcher parsing and matching #6082

[knutwannheden]

An ANTLR grammar producing an AST should allow us to achieve better performance than using regex parsing. For MethodMatcher I took a different approach, as that grammar is so very simple and the input is typically so short (typically in the range of 10-50 bytes), so that the overhead of the ANTLR parsing was quite large. For XPath and JSONPath I think an ANTLR grammar is quite sensible, as these grammars are more complex and it will be much easier to get the implementation to being feature complete, if we use a parser generator like ANTLR.

[BrendanHart]

Appreciate the insights @knutwannheden ! Will take a look.