Switching off .xml extension for xml language the (other) xml checks no longer work

[ca-stefan-cordes]

When switching off
Administration-> Configuration->General Settings->XML and delete the .xml "File suffixes"
to enable mule-sonarqube to work with .xml files (as documented),
(btw. it is Administration-> Configuration -> Language -> XML in Sonar Version 8.1 )

the rules for XML no longer apply.

E.g. XPath rules are switched off:

Please add another approach to scan xml files with this mule plugin.

Log of mvn sonar:sonar differs:
With .xml:

Without .xml:

[ca-stefan-cordes]

I created a fork with *.mule as extension which requires to copy/rename the files before analysis:

https://github.com/c-a-services/mule-sonarqube-plugin/tree/use-mule-file-extension

(Just changing in sonar config is not sufficient as MuleFilePredicate still searching for .xml, see #20 )

[fperezpa]

Hi @ca-stefan-cordes, you could disable the XML plugin at project level instead of to all the server instance. Does that work for you?

[ca-stefan-cordes]

HI @fperezpa,

1. that would be a huge manual work to maintain each project (when it is firstly created we normally do not perfom manual tasks).
2. the xml plugin is checking mule apps via xpath as well, e.g. log4j2.xml to not have level="DEBUG"

For 2. we could integrate the xpath expressions in the rules-4.xml as workaround, but then e.g. "log4j2.xml" needs to be checked by mule, too - not nice.

My current workaround is to copy all mule-xml files via ant to *.mule and change the language for this plugin to .mule.
(which will work fine with #21 )

pom.xml:

<profile>
	<id>sonar-run</id>
	<build>
		<plugins>
			<plugin>
				<artifactId>maven-antrun-plugin</artifactId>
				<version>3.0.0</version>
				<executions>
					<execution>
						<id>copy-file</id>
						<phase>validate</phase>
						<goals>
							<goal>run</goal>
						</goals>
						<configuration>
							<target>
								<echo>Prepare for sonar.</echo>
								<copy
									todir="${project.basedir}/src/test/test-sonar/"
									failonerror="false"
									overwrite="true">
									<fileset dir="${project.basedir}/src/main/mule/">
										<include name="**/*.xml" />
									</fileset>
									<mapper
										type="glob"
										from="*"
										to="*.mule" />
								</copy>
							</target>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
</profile>

With
mvn validate sonar:sonar -P sonar-run

Additionally I digged a little bit in the sonar architecture and found that e.g. the file-path (src/main/mule/**/.xml) can be changed for a language as well but still the exception comes up (as xml plugin is **/.xml):

"can not be decided as the file matches patterns"

This problem is more likely a restriction of the sonar architecture and the best way to solve would be to define mule files with an own extension in AnypointStudio directly (like *.mule or *.mulexml) but that probably is a large change to your platform...

So for this issue I think we can work with the workaround.

I can add a section to the readme.md to via this issue how to co-existence with the xml plugin and then all should be fine.

[chirubtech]

The simple fix for this issue is to disable Mule plugin completely by updating File Suffixes for the Mule plugin.

1. Administration → Mule → File Suffixes
   Update sonar.mule.file.suffixes from .xml to .mule (any extension which is not already as part of sonarqube)

2. For scanning Mule projects add the following properties in settings.xml (or in pom file)

<sonar.lang.patterns.xml>null</sonar.lang.patterns.xml>
<sonar.mule.file.suffixes>.xml</sonar.mule.file.suffixes>

Note: Alternatively these values can be passed as VM arguments while running sonar scan.

-Dsonar.lang.patterns.xml=null -Dsonar.mule.file.suffixes=.xml

This fix will help if your Sonarqube server is shared across teams and you don't want to disturb other projects those are using XML Plugin.

@fperezpa @ca-stefan-cordes

[ca-stefan-cordes]

Hi @chirubtech,
great tip to not disturb XML plugin using for other (non-mule) projects and avoid copying/rename mule-files.

Unfortunately we currently have XML plugin rules (xpath) for mule-applications :-(

When this plugin is based on javax.xml.xpath (see #23) it will be easy to move all our xml-plugin-mule-xpath rules to rules-4.xml and so we can use your workaround as mule projects no longer will need XML-Plugin.

[BevanG]

The simple fix for this issue is to disable Mule plugin completely by updating File Suffixes for the Mule plugin.

1. Administration → Mule → File Suffixes
   Update sonar.mule.file.suffixes from .xml to .mule (any extension which is not already as part of sonarqube)
2. For scanning Mule projects add the following properties in settings.xml (or in pom file)

<sonar.lang.patterns.xml>null</sonar.lang.patterns.xml>
<sonar.mule.file.suffixes>.xml</sonar.mule.file.suffixes>

Note: Alternatively these values can be passed as VM arguments while running sonar scan.

-Dsonar.lang.patterns.xml=null -Dsonar.mule.file.suffixes=.xml

This fix will help if your Sonarqube server is shared across teams and you don't want to disturb other projects those are using XML Plugin.

@fperezpa @ca-stefan-cordes

Thank you. I figured out the first step but couldn't see how to enable the Mule plugin (and disable default xml) for running on Mule projects. I can automate this in CICD so you've given me the solution I need.

Given the age of this ticket you haven't found a way to disable and enable plugins for certain projects do you? Not having an enable/disable or project include param in pom.xml or in server.xml seems to be a glaring omission to me,

[PipeItToDevNull]

Same as above, if multiple projects use one server not being able to make modifications per-project is a real issue.

[hamidos]

Hello,
As stated in Xml file extension is binded to multiple Language , we maybe able to solve this issue by modifying the plugin code:

The SonarQube API already makes it possible for a plugin to raise issues on any source file without requiring users to associate all possible file suffixes to this plugin. I suppose that the authors of the mule plugin are not aware of that. As a user of this plugin, you should explain your problem to them. SonarSource cannot fix the mule plugin.