[core] Select XPath version in violationSuppressXPath #1676
Comments
|
@Vampire PMD has always supported XPath 1.0, 2.0 and "1.0-compatibility" for writing XPath rules. There is nothing new here. This property however, has always been treated as an XPath 1.0 expression (again, nothing changed). I agree however, that as we push towards dropping 1.0 eventually (and even adding 3.0 support), we need to have such support across the board. Without adding an extra property, I see no reasonable way of doing this however… probably @adangel or @oowekyala have better ideas 'though |
|
I see all three modes in the designer, except for it 2.0 and 1.0-compatibility not working as mentioned in the other issue. As 2.0 is not backwards compatible and expressions that are syntactically valid in both, 1.0 and 2.0 could behave quite differently (e. g. |
|
The Alternatively we could stop exposing that violationSuppressXPath and violationSuppressRegex are properties in the XML and instead introduce some syntactic sugar with 7.0.0. I think it makes sense, just like we're introducing some sugar for Xpath rule properties. E.g. |
|
Also fine. :-) |
|
We're considering making XPath rule declarations shorter by specializing the <xpath-rule name="Name" language="java" message="string">
<description>
A description
</description>
<xpath><![CDATA[
//ClassOrInterfaceDeclaration
[@Abstract='true' and @Interface='false']
]]><xpath>
</xpath-rule>Doing that has other pleasing consequences that are described on the wiki page I linked. This is a change considered for 7.0.0 and nothing is implemented yet. Anyway it's quite natural to add an element for suppression patterns. They'd hide the implementation, enable IDE completion and inline doc, etc. |
|
Ah, I see, I thought there might be some sugar for using the xpath rules that I missed to use. Sounds reasonable though. |
|
Oh, you even can add conditions, so you can restrict the injection with an XPath condition, I just don't get it working properly if it is not broken currently (https://youtrack.jetbrains.com/issue/IDEA-207620). |
We don't maintain the intellij plugin, submit a feature request on https://github.com/amitdev/PMD-Intellij for that. Not sure how responsive they are though |
|
I did't mean in the IJ plugin, but in the XSD if this is possible, I didn't find anything though, I created https://youtrack.jetbrains.com/issue/IDEA-207628 as feature request. |
oowekyala
changed the title
oowekyala
added
the
in:xpath
|
Ok so we need a transition plan for this on master that fits within #1687. The current problem is
Additionally, this doesn't need to be implemented via a property, and some sugar would be nice. I'm thinking, in order to support early migration, we could just make a decision about what the new XML syntax is to suppress violations via XPath, and then make that new syntax available on master, but only working with XPath 2. Eg if we add a child element to <rule ref="...">
<suppressions>
<xpath>./Some/XPath2</xpath>
</suppressions>
</rule>Where the version of this query would be 2.0 by defaut. So, users can migrate by transforming <properties>
<property name="violationSuppressXPath" value="./Some/XPath1" />
</properties>to the above syntax, and migrating their xpath query to 2.0 at the same time The advantage of a dedicated
|
|
At this point I don't think it's worth expending the effort of doing this change to the schema in PMD 6. The incompatibilities between XPath 1 and 2 are few and far between. XPath expressions will be broken by the new grammar in PMD 7 anyway. When releasing PMD 7, we can use the XSLT migrator to convert the property to the new element form, and then point the user to the elements that need to be reviewed, because they've probably been invalidated by changes to the grammar. The changes to the schema can be scheduled for PMD 7 (I'll copy this comment to the wiki). In the meantime, we could also decide to make |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Moving the comments from #2523 to here:
|
As the rule designer has a toggle for XPath 1.0 vs. 2.0, I assume XPath 2.0 should be supported?
Because if I use some
@BeginColumn = (17, 60)in aviolationSuppressXPathvalue, I get a syntax error.The text was updated successfully, but these errors were encountered: