[core] Upgrade Saxon, add XPath 3.1, remove Jaxen#2614
Conversation
Remove Jaxen, port function defs Use enum to represent XPath version Move to internal package Fix style Refactor functions
LazyExpression does not exist anymore
Saxon HE doesn't implement typed attributes, I guess that's part of the package of schema aware processing :( We could possibly replace all AttributeGetter exprs with TypedAttributeGetter or something, but this will be very hard as there is no visitor pattern or cloning pattern implemented widely in saxon (Expression has 166 implementations). We could literally replace the class for AttributeGetter in the saxon jar, provided it's legal
The RootNode corresponds to both an element and a document node
This reverts commit 3d463d7. This can be done later.
This reverts commit 7b282ce.
eg (//a | //b)/c
Not as stable as 8, but fixes a bug in the optimizer
Update default version to 3.1
Generated by 🚫 Danger |
Basically, users shouldn't really have a choice of XPath version, esp. if all versions we support are compatible.
adangel
left a comment
There was a problem hiding this comment.
Thanks for doing this! Looks good.
This PR actually fixes #1687, doesn't it?
I've collected the following comments, which I added to #2523:
[doc] Make sure, XPath changes are documented in a migration guide PMD 6->7 (see also #1139)
That means: The section migrating from XPath 1.0 -> XPath 2.0 should be moved to the migration
guide PMD6->7
since only XPath 2.0 (actually XPath 3.1) will be supported with PMD 7.Move XPathRule to correct package. For compatibility, we could keep a @DeprecatedUntilPmd700
subclass in place. Depends on the final ruleset xml format.Cleanup duplicated license headers in files. Appeared after moving files around.
[api] AbstractXPathFunctionDef/XPathHandler -> uses saxon api and leaks this into pmd api for
language implementations[deprecations] The property version of XPathRule is deprecated and will be removed.
-> eventually, we should remove it in pmd7, don't we? hm... it's not deprecated in pmd6, right?
because you can still switch between 1.0, 1.0-compat and 2.0. but maybe we can deprecated in
already in pmd6, defaulting to xpath 2.0, then we could remove it in pmd7?
-> it seems, the version property is already deprecated on pmd6ViolationSuppressor: xpath suppressions handling. The parsed xpath expr should be stored
instead of the string.
It's deprecated on master but I think not as a property ( Thanks for adding those todos, that's super helpful |
They're transitively gotten from pmd-core, but for some use cases this is nicer eg `mvn install -pl pmd-java`, given that pmd-core was already installed locally, should succeed. If the dependencies are not mentioned explicitly, for some reason this fails. Before #2614, pmd-core was shaded with its dependencies and this wasn't necessary
Part of #2523
I don't think this is completely ready, but I'm putting this up for laterThis is ready now, the sooner it's merged the betterDescribe the PR
violationSuppressXPathuse XPath 3.1nspmd.lang.rule.xpath. This includes classAttribute, which some clients may depend on as it's exposed onNode.Node::hasDescendantMatchingXPathby updating the last imagesNode::findChildrenWithXPathfor now. I think it would be much easier to scrap that after the new java grammar is merged. The method now uses Saxon, which caused no problemsAlso one new XPath optimisation, is that rules property values are now inlined in the xpath expression. This allows pruning some branches that would never be taken, because some property is false.
Related issues
Ready?
./mvnw clean verifypasses (checked automatically by travis)