SonarQube中Mule应用pom.xml自定义规则不生效求助

I’ve run into this exact namespace issue with Maven POMs in SonarQube before—let’s get your rules working properly. The core problem here is that your POM uses the official Maven XML namespace (http://maven.apache.org/POM/4.0.0), but your XPath expressions aren’t accounting for it. Even though the element names look right, XPath ignores them without namespace handling, which is why your rules aren’t triggering as expected.

Let’s fix each rule one by one:

1. Model Version Validation (Rule ID: 2) #

Your original rule checks if modelVersion equals 4.0.0, but SonarQube rules work by matching violations (not compliant values). We need to reverse the logic to flag nodes where the value isn’t 4.0.0, while keeping the namespace-agnostic local-name check:

<rule id ="2" name="Pom Model Version should be 4.0.0" description="Pom Model Version should be 4.0.0" severity="MAJOR" type="code_smell">
  //*[local-name()='project']/*[local-name()='modelVersion'][text() != '4.0.0']
</rule>

In your sample POM, modelVersion is correct, so this rule won’t fire here—but it will catch any invalid versions once fixed.

2. Artifact ID Length Check (Rule ID: 3) #

First, update the applies attribute to target POM files specifically (use pom instead of application—SonarQube uses this to scope rules to the right file types). Then keep the length check with proper local-name handling:

<rule id="3" name="Application Name is too long" description="Application Name is too long, give a proper name" severity="MAJOR" applies="pom" type="code_smell">
  string-length(//*[local-name()='project']/*[local-name()='artifactId']) > 20
</rule>

Your sample artifactId ("security") is only 8 characters, so this rule won’t trigger here, but it will catch longer values as intended.

3. Mule Runtime Version Rule (Rule ID: 4) #

Again, reverse the logic to flag violations (when app.runtime isn’t 4.2.0) and keep the namespace-agnostic path:

<rule id ="4" name="Mule Runtime Version should be 4.2.0" description="Mule Runtime Version should be 4.2.0" severity="MAJOR" type="code_smell">
  //*[local-name()='project']/*[local-name()='properties']/*[local-name()='app.runtime'][text() != '4.2.0']
</rule>

Your sample POM has app.runtime set to 4.3.0-20201013, so this rule should now trigger correctly once you apply the fix.

Quick Checks to Confirm Everything Works #

• Double-check SonarQube’s scan scope: Your sonar.sources is set to /, which should include the POM, but make sure the file isn’t excluded in your project settings.
• Test XPath locally: Use an XML editor or browser dev tools to run the corrected XPath against your POM—you should see the violating nodes show up immediately.
• Verify rule activation: Ensure these rules are added to your active quality profile and that the profile is applied to your Mule project in SonarQube.

内容的提问来源于stack exchange，提问作者sdevis