When I develop the custom plugin the sonar-xml version was 1.5.1 and and both plugins work fine together in SonarQube 5.6.6.
Now I’m upgrading the SonarQube version to 7.9.1 and his plugins, but when the analysis is performed with sonar-xml-plugin v2.0.1 and my custom xml plugin based on sonar-xml-plugin v1.5.1 I get an error trying to save highlighting for XML files and an Issue in those files with issues detected by both plugins:
Parse error: Trying to save highlighting twice for the same file is not supported: samplefile.xml
Rule: XML parser failure (xml:S2260)
After seeing the javadoc of NewHighlighting class I came to the conclusion that it is a deliberate decision but I need to use both plugins and I would not want to leave them without updating because I also want to see the issues in SonarLint .
And no, XPath templates of sonar-xml-plugin are not enough for the requirements of my rules.
Has anyone somewhere had the same problem? Some idea to solve the problem? Thanks a lot in advance!
Hello @irinacen, and welcome on this community forum.
If you only needs your custom plugin for some extra rules targeting XML, then I would suggest to remove all the rest from your fork. Metrics, highlighting, languages definition, and let this responsibility to the official XML plugin.
Would you prefer to have access to an approach allowing you to implements your own custom rules, in Java, relying on some SonarXML API, “à la SonarJava” ?
Hello @Michael, thanks a lot for your fast response and thanks for your suggestion.
Really my custom xml plugin has more busines logic (like project type recognition based on file path, decide which files are checked for each check, etc.) in addition to metrics, highlighting, etc. but after thinking it and especially after your response I think that “merge” both plugins in one is the only possible solution to maintain both checks and logic, so I will do it.
Answering your question I was happy with my custom plugin until I found this problem That is, I think that the SonarJava API is a bit restrictive if you need do things more complex that develop custom rules as in my case, so for me fork the plugins was a great solution.
Anyway I don’t think it’s a bad idea to have an API in order to develop a bit complex XML checks.
Out of curiosity, can I ask to you why you added these limitation to files highlight?
Indeed, and it is not intended to do more for the time being. We assume that people willing to do more will probably feed SonarQube using directly the SonarQube public API. SonarJava only bring custom rules to public.
I’m not participating to the development of this part, but I guess that would be to guarantee consistency. For instance, who to trust if 2 plugins are feeding highlighting data with some overlaps?