Skip to:
When using the following xpath expression not requiring any namespace:
//dependency/artifactId[starts-with(text(),'mule-http-connector')]//following-sibling::version[not(starts-with(text(),'1.6'))]
Then the XPathCheck is behaving differently if a file use namespace or not. In particular, the rule will raise an issue in the following file:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <dependencies> <dependency> <groupId>org.mule.connectors</groupId> <artifactId>mule-http-connector</artifactId> <version>1.7.2</version> <classifier>mule-plugin</classifier> </dependency> </dependencies> </project>
While it won’t on the following equivalent file, except that it contains a valid namespace:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <dependencies> <dependency> <groupId>org.mule.connectors</groupId> <artifactId>mule-http-connector</artifactId> <version>1.7.2</version> <classifier>mule-plugin</classifier> </dependency> </dependencies> </project>
In this case, the root of the problem lies in the xPathCheck decision of using a namespace-baed approach to find issues, while there is no reason to do so. The test used to decide between using or not namespace is wrong, and does not support ::.
::
Verified manually on my local instance with a custom rule using namespaces and `::`
When using the following xpath expression not requiring any namespace:
//dependency/artifactId[starts-with(text(),'mule-http-connector')]//following-sibling::version[not(starts-with(text(),'1.6'))]Then the XPathCheck is behaving differently if a file use namespace or not. In particular, the rule will raise an issue in the following file:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <dependencies> <dependency> <groupId>org.mule.connectors</groupId> <artifactId>mule-http-connector</artifactId> <version>1.7.2</version> <classifier>mule-plugin</classifier> </dependency> </dependencies> </project>While it won’t on the following equivalent file, except that it contains a valid namespace:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <dependencies> <dependency> <groupId>org.mule.connectors</groupId> <artifactId>mule-http-connector</artifactId> <version>1.7.2</version> <classifier>mule-plugin</classifier> </dependency> </dependencies> </project>In this case, the root of the problem lies in the xPathCheck decision of using a namespace-baed approach to find issues, while there is no reason to do so. The test used to decide between using or not namespace is wrong, and does not support
::.