4.5.2 API #435

guwirth · 2015-03-01T23:06:10Z

Current problems below.

Is someone working on this?
Is someone familiar with the problems?
close Rebase the plugin to the API of the current LTS SQ version (4.5.1) #357

-------------------------------------------------------------
COMPILATION ERROR : 
-------------------------------------------------------------
org/sonar/plugins/cxx/CxxRuleRepository.java:[24,27] cannot find symbol
  symbol:   class AnnotationRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/CxxRuleRepository.java:[26,27] cannot find symbol
  symbol:   class RuleRepository
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/CxxRuleRepository.java:[29,40] cannot find symbol
  symbol: class RuleRepository
org/sonar/plugins/cxx/CxxRuleRepository.java:[33,17] cannot find symbol
  symbol:   class AnnotationRuleParser
  location: class org.sonar.plugins.cxx.CxxRuleRepository
org/sonar/plugins/cxx/CxxRuleRepository.java:[35,28] cannot find symbol
  symbol:   class AnnotationRuleParser
  location: class org.sonar.plugins.cxx.CxxRuleRepository
org/sonar/plugins/cxx/veraxx/CxxVeraxxRuleRepository.java:[24,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[32,27] cannot find symbol
  symbol:   class RuleRepository
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[33,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[39,57] cannot find symbol
  symbol: class RuleRepository
org/sonar/plugins/cxx/veraxx/CxxVeraxxRuleRepository.java:[38,63] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.veraxx.CxxVeraxxRuleRepository
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[43,17] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.utils.CxxAbstractRuleRepository
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[50,65] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.utils.CxxAbstractRuleRepository
org/sonar/plugins/cxx/valgrind/CxxValgrindRuleRepository.java:[24,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/valgrind/CxxValgrindRuleRepository.java:[38,65] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.valgrind.CxxValgrindRuleRepository
org/sonar/plugins/cxx/externalrules/CxxExternalRuleRepository.java:[30,27] cannot find symbol
  symbol:   class RuleRepository
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/externalrules/CxxExternalRuleRepository.java:[31,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/externalrules/CxxExternalRuleRepository.java:[38,48] cannot find symbol
  symbol: class RuleRepository
org/sonar/plugins/cxx/externalrules/CxxExternalRuleRepository.java:[43,17] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.externalrules.CxxExternalRuleRepository
org/sonar/plugins/cxx/externalrules/CxxExternalRuleRepository.java:[46,36] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.externalrules.CxxExternalRuleRepository
org/sonar/plugins/cxx/cppcheck/CxxCppCheckRuleRepository.java:[24,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/cppcheck/CxxCppCheckRuleRepository.java:[39,65] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.cppcheck.CxxCppCheckRuleRepository
org/sonar/plugins/cxx/rats/CxxRatsRuleRepository.java:[24,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/rats/CxxRatsRuleRepository.java:[38,61] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.rats.CxxRatsRuleRepository
org/sonar/plugins/cxx/compiler/CxxCompilerGccRuleRepository.java:[24,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/compiler/CxxCompilerGccRuleRepository.java:[38,68] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.compiler.CxxCompilerGccRuleRepository
org/sonar/plugins/cxx/pclint/CxxPCLintRuleRepository.java:[24,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/pclint/CxxPCLintRuleRepository.java:[38,63] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.pclint.CxxPCLintRuleRepository
org/sonar/plugins/cxx/compiler/CxxCompilerVcRuleRepository.java:[24,27] cannot find symbol
  symbol:   class XMLRuleParser
  location: package org.sonar.api.rules
org/sonar/plugins/cxx/compiler/CxxCompilerVcRuleRepository.java:[38,67] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.compiler.CxxCompilerVcRuleRepository
org/sonar/plugins/cxx/CxxRuleRepository.java:[37,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.CxxRuleRepository
org/sonar/plugins/cxx/CxxRuleRepository.java:[41,3] method does not override or implement a method from a supertype
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[63,11] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.utils.CxxAbstractRuleRepository
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[63,41] cannot find symbol
  symbol:   class XMLRuleParser
  location: class org.sonar.plugins.cxx.utils.CxxAbstractRuleRepository
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[65,37] cannot find symbol
  symbol:   method getClass()
  location: class org.sonar.plugins.cxx.utils.CxxAbstractRuleRepository
org/sonar/plugins/cxx/utils/CxxAbstractRuleRepository.java:[59,3] method does not override or implement a method from a supertype
org/sonar/plugins/cxx/veraxx/CxxVeraxxRuleRepository.java:[40,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.veraxx.CxxVeraxxRuleRepository
org/sonar/plugins/cxx/valgrind/CxxValgrindRuleRepository.java:[40,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.valgrind.CxxValgrindRuleRepository
org/sonar/plugins/cxx/externalrules/CxxExternalRuleRepository.java:[48,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.externalrules.CxxExternalRuleRepository
org/sonar/plugins/cxx/externalrules/CxxExternalRuleRepository.java:[57,35] cannot find symbol
  symbol:   method getClass()
  location: class org.sonar.plugins.cxx.externalrules.CxxExternalRuleRepository
org/sonar/plugins/cxx/externalrules/CxxExternalRuleRepository.java:[53,3] method does not override or implement a method from a supertype
org/sonar/plugins/cxx/cppcheck/CxxCppCheckRuleRepository.java:[41,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.cppcheck.CxxCppCheckRuleRepository
org/sonar/plugins/cxx/rats/CxxRatsRuleRepository.java:[40,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.rats.CxxRatsRuleRepository
org/sonar/plugins/cxx/compiler/CxxCompilerGccRuleRepository.java:[40,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.compiler.CxxCompilerGccRuleRepository
org/sonar/plugins/cxx/pclint/CxxPCLintRuleRepository.java:[40,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.pclint.CxxPCLintRuleRepository
org/sonar/plugins/cxx/compiler/CxxCompilerVcRuleRepository.java:[40,5] cannot find symbol
  symbol:   method setName(java.lang.String)
  location: class org.sonar.plugins.cxx.compiler.CxxCompilerVcRuleRepository
45 errors

jmecosta · 2015-03-02T06:28:45Z

We discuss this before, the issue here is that we are not using a recommended way of defining rules. The XML that we put in the web ui is no more supported. We have two alternatives we get the XML parser file from earlier versions and keep it in the cxx plugin so we can still use the same way of defining rules or we drop it and use only the recommended way using template rules. Those are already available so we would only need to remove the properties and the extension that parses the XML for each sensor.

I promise to provide a tool to use the XML we have and create template rules accordingly.

guwirth · 2015-03-02T17:30:54Z

I'm still thinking that the possibility to add rules from other tools with a simple XML rule file is one of the biggest advantages of the cxx plugin.

missing symbols using 4.5.2:

location: package org.sonar.api.rules
- symbol: class AnnotationRuleParser
- symbol: class RuleRepository
- symbol: class XMLRuleParser

Found this link:
http://sonarqube.15.x6.nabble.com/sonar-dev-Deprecation-of-XMLRuleParser-td5031098.html

the replacement is RulesDefinition extension point
http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.sonar/sonar-plugin-api/4.5.2/org/sonar/api/server/rule/RulesDefinition.java#RulesDefinition

jmecosta · 2015-03-02T18:59:50Z

heres an example of that in use
https://github.com/SonarCommunity/sonar-sonargraph/blob/master/src/main/java/com/hello2morrow/sonarplugin/api/SonargraphRulesRepository.java

ive took a look at it. and would need to convert the xml from the ui to this... not sure whats best

jmecosta · 2015-03-02T19:02:20Z

plus not sure how this works with the current rules that are defined in the resources xml

guwirth · 2015-03-02T19:21:07Z

Are there opinions from others?
Which is the right way to go?

guwirth · 2015-03-02T19:42:55Z

There is also the class RulesDefinitionXmlLoader:

http://javadocs.sonarsource.org/4.4/apidocs/org/sonar/api/server/rule/RulesDefinitionXmlLoader.html

jmecosta · 2015-03-02T19:46:21Z

seems the format is different than what we use. but guess this would be a way of doing it

guwirth · 2015-03-02T19:51:56Z

For conversation of the rules files we could provide an XSL.
Question is: Keep XML in UI or move it to a file again?

Still like to here other opinions.

jmecosta · 2015-03-02T20:09:37Z

dont think you can have them in file anymore, that option has been deprecated in favor of having those in web ui. at least it was the reason why we decided to put them in web ui in first place.

there are 2 big advantages of defining those in using custom rules:
. no need to restart server every time rules get updated.
. rules are properly tracked by rule history in server.

third thing is sensors i am using provided by sonar guys use custom rules has the way extending rules. so if doing the same most of the documentation is already provided by platform.

guwirth · 2015-03-03T06:14:57Z

Input for RulesDefinitionXmlLoader is a stream. So could also be a file again?
(What does not mean that I prefer this.)

jmecosta · 2015-03-03T06:20:21Z

But the case to use this is to include the file in the jar only, where in
server are you keeping the file? If sonar guys decide to move the jar to
another location or something else this will be broken. We should not
really ask users to keep files in server as we are not following the
recommended practices

On Tue, Mar 3, 2015, 08:14 Günter Wirth [email protected] wrote:

Input for RulesDefinitionXmlLoader is a stream. So could also be a file
again?
(What does not mean that I prefer this.)

—
Reply to this email directly or view it on GitHub
#435 (comment).

guwirth · 2015-03-03T07:11:57Z

You are right. This argument convinced me.

jmecosta · 2015-03-03T07:36:18Z

But still the question is use template rules or crate helper class to read
from property and create rules based on rules definition. Those tend to be
considered less stable and likely change from one version to another. As
the rest api should be much more stable and should not change often. For
the argument of keeping it simple from the plugin side and make it a more
stable feature I would drop the web ui properties and solely use rest api
to define those rules

On Tue, Mar 3, 2015, 09:12 Günter Wirth [email protected] wrote:

You are right. This argument convinced me.

—
Reply to this email directly or view it on GitHub
#435 (comment).

wenns · 2015-03-03T22:58:01Z

Hi guys,

Compiling against the 4.5 API: yes, the rule repositories should be reworked. AFAIR, sonar-php can be looked at for examples how to do that. https://github.com/SonarCommunity/sonar-php/blob/master/sonar-php-plugin/src/main/java/org/sonar/plugins/php/PHPRulesDefinition.java
As for the rule format: Im not familiar with the newest stuff. The new definition and the description of the class:

http://javadocs.sonarsource.org/4.4/apidocs/org/sonar/api/server/rule/RulesDefinitionXmlLoader.html

looks like there is just a change in the format, conceptually its the same. I.e. you have some XML files, probably packaged with your plugin, and there is an API (a class) which can be used to read them in.

@jmecosta not sure what you mean by using the REST api etc. When is the rule creation supposed to run? Still at the plugin load time, no?
I mean: the installation procedure of a language plugin (including the initial rule creation) will remain the same, i.e. user clicks on a link in update center and (in future optionally?) restarts the server?

jmecosta · 2015-03-04T06:24:44Z

Not for custom rules, that was the main thing we were discussing. These
days you will need to restart the server to take new rules into use. For
example if you take the XML out of the web ui you will loose all your rules
causing then all issues to be disappear. Once you notice and you enabled
them again all new issues appear again. The template rules solve this,
there is a proper version for those.

So we could use the rest api to create the custom rules instead of having a
XML in the web ui.

For rules that come bundled I agree on what you propose

On Wed, Mar 4, 2015, 00:58 Waleri Enns [email protected] wrote:

Hi guys,

Compiling against the 4.5 API: yes, the rule repositories should be
reworked. AFAIR, sonar-php can be looked at for examples how to do that.

As for the rule format: Im not familiar with the newest stuff. The new
definition and the description of the class:

http://javadocs.sonarsource.org/4.4/apidocs/org/sonar/api/server/rule/RulesDefinitionXmlLoader.html

looks like there is just a change in the format, conceptually its the
same. I.e. you have some XML files, probably packaged with your plugin, and
there is an API (a class) which can be used to read them in.

@jmecosta https://github.com/jmecosta not sure what you mean by using
the REST api etc. When is the rule creation supposed to run? Still at the
plugin load time, no?
I mean: the installation procedure of a language plugin (including the
initial rule creation) will remain the same, i.e. user clicks on a link in
update center and (in future optionally?) restarts the server?

—
Reply to this email directly or view it on GitHub
#435 (comment).

guwirth · 2015-03-04T17:37:48Z

Sounds like both makes sense. Seems they do not exclude each other:

reading rules during server start from plugin specific subfolder
use REST API:
- http://en.wikipedia.org/wiki/Representational_state_transfer
- http://docs.sonarqube.org/display/SONAR/Web+Service+API

guwirth · 2015-03-22T07:59:34Z

Looking to the source code of RulesDefinitionXmlLoader the reader is backward compatible. Means supporting also our current XML format for rules.
https://github.com/SonarSource/sonarqube/blob/master/sonar-plugin-api/src/main/java/org/sonar/api/server/rule/RulesDefinitionXmlLoader.java

guwirth · 2015-04-02T06:06:48Z

FYI. Working on this. Will provide solution next days.

guwirth · 2015-04-02T08:43:27Z

Add a first preview. Unit tests still failing...

guwirth · 2015-04-02T15:45:47Z

fix some unit tests, nearly functional now.

still open:

CxxCommonRulesEngineTest unit tests are not running, maybe @jmecosta can have a look (something to do with CxxRuleRepository?)
- sonar-cxx-plugin\src\test\java\org\sonar\plugins\cxx\CxxCommonRulesEngineTest.java
- sonar-cxx-plugin\src\main\java\org\sonar\plugins\cxx\CxxRuleRepository.java
MSTestResultsProviderTest does not compile with 4.5 API? Maybe @Bertk can have a look
- sonar-cxx-plugin\src\test\java\org\sonar\plugins\cxx\xunit\MSTestResultsProviderTest.java

jmecosta · 2015-04-02T17:35:31Z

Ok I take a look, likely some common rules have been dropped

On Thu, Apr 2, 2015, 18:45 Günter Wirth [email protected] wrote:

fix some unit tests, nearly functional now.

still open:

CxxCommonRulesEngineTest unit tests are not running, maybe @jmecosta
https://github.com/jmecosta can have a look (something to do with
CxxRuleRepository?)
-
sonar-cxx-plugin\src\test\java\org\sonar\plugins\cxx\CxxCommonRulesEngineTest.java
-
sonar-cxx-plugin\src\main\java\org\sonar\plugins\cxx\CxxRuleRepository.java
-

MSTestResultsProviderTest does not compile with 4.5 API? Maybe @Bertk
https://github.com/Bertk can have a look
-
sonar-cxx-plugin\src\test\java\org\sonar\plugins\cxx\xunit\MSTestResultsProviderTest.java

—
Reply to this email directly or view it on GitHub
#435 (comment).

guwirth · 2015-04-03T07:12:34Z

@jmecosta I think I'm one step closer to the goal. Getting now 'name of rule is empty'?

jmecosta · 2015-04-03T09:42:47Z

seems tests have been updated in the java plugin:

see
jmecosta@be5d876

and
https://github.com/SonarSource/sonar-java/blob/master/sonar-java-plugin/src/test/java/org/sonar/plugins/java/JavaCommonRulesEngineTest.java

guwirth · 2015-04-03T14:18:41Z

Think I got it. Tags of checks are different now.
https://github.com/SonarSource/sonar-java/blob/master/java-checks/src/main/java/org/sonar/java/checks/AnonymousClassesTooBigCheck.java

Bertk · 2015-04-03T16:54:18Z

Hi, can you please give me some details on the compile Errors. I cannot reproduce it (
https://github.com/Bertk/sonar-cxx/tree/use-4.5.2-API-).

I see only some failing tests …

Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.002 sec <<< FAILURE! - in org.sonar.plugins.cxx.CxxCommonRulesEngineTest
provide_extensions(org.sonar.plugins.cxx.CxxCommonRulesEngineTest)  Time elapsed: 0 sec  <<< ERROR!
java.lang.IllegalStateException: Name of rule [repository=cxx, key=NotAllowedToDoTag] is empty
        at org.sonar.api.server.rule.RulesDefinition$NewRule.validate(RulesDefinition.java:707)
        at org.sonar.api.server.rule.RulesDefinition$NewRule.access$900(RulesDefinition.java:514)
        at org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.<init>(RulesDefinition.java:453)
        at org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.<init>(RulesDefinition.java:443)
        at org.sonar.api.server.rule.RulesDefinition$Context.registerRepository(RulesDefinition.java:337)
        at org.sonar.api.server.rule.RulesDefinition$Context.access$500(RulesDefinition.java:304)
        at org.sonar.api.server.rule.RulesDefinition$NewRepositoryImpl.done(RulesDefinition.java:422)
        at org.sonar.plugins.cxx.CxxRuleRepository.define(CxxRuleRepository.java:41)
        at org.sonar.plugins.cxx.CxxCommonRulesEngineTest.provide_extensions(CxxCommonRulesEngineTest.java:42)

enable_common_rules(org.sonar.plugins.cxx.CxxCommonRulesEngineTest)  Time elapsed: 0 sec  <<< ERROR!
java.lang.IllegalStateException: Name of rule [repository=cxx, key=NotAllowedToDoTag] is empty
        at org.sonar.api.server.rule.RulesDefinition$NewRule.validate(RulesDefinition.java:707)
        at org.sonar.api.server.rule.RulesDefinition$NewRule.access$900(RulesDefinition.java:514)
        at org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.<init>(RulesDefinition.java:453)
        at org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.<init>(RulesDefinition.java:443)
        at org.sonar.api.server.rule.RulesDefinition$Context.registerRepository(RulesDefinition.java:337)
        at org.sonar.api.server.rule.RulesDefinition$Context.access$500(RulesDefinition.java:304)
        at org.sonar.api.server.rule.RulesDefinition$NewRepositoryImpl.done(RulesDefinition.java:422)
        at org.sonar.plugins.cxx.CxxRuleRepository.define(CxxRuleRepository.java:41)
        at org.sonar.plugins.cxx.CxxCommonRulesEngineTest.enable_common_rules(CxxCommonRulesEngineTest.java:54)

guwirth · 2015-04-04T07:05:09Z

Hello @Bertk. After many other changes the problem has gone. Only remaining problem seems to be CxxCommonRulesEngineTest. Problem below was usage of obsolete @rule in all checks. I also changed this, see last upload. Currently I'm getting NoClassDefFound and I have no glue why?

Am 03.04.2015 um 18:54 schrieb Bert [email protected]:

Hi, can you please give me some details on the compile Errors. I cannot reproduce it (
https://github.com/Bertk/sonar-cxx/tree/use-4.5.2-API-).

I see only some failing tests …

Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.002 sec <<< FAILURE! - in org.sonar.plugins.cxx.CxxCommonRulesEngineTest
provide_extensions(org.sonar.plugins.cxx.CxxCommonRulesEngineTest) Time elapsed: 0 sec <<< ERROR!
java.lang.IllegalStateException: Name of rule [repository=cxx, key=NotAllowedToDoTag] is empty
at org.sonar.api.server.rule.RulesDefinition$NewRule.validate(RulesDefinition.java:707)
at org.sonar.api.server.rule.RulesDefinition$NewRule.access$900(RulesDefinition.java:514)
at org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.(RulesDefinition.java:453)
at org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.(RulesDefinition.java:443)
at org.sonar.api.server.rule.RulesDefinition$Context.registerRepository(RulesDefinition.java:337)
at org.sonar.api.server.rule.RulesDefinition$Context.access$500(RulesDefinition.java:304)
at org.sonar.api.server.rule.RulesDefinition$NewRepositoryImpl.done(RulesDefinition.java:422)
at org.sonar.plugins.cxx.CxxRuleRepository.define(CxxRuleRepository.java:41)
at org.sonar.plugins.cxx.CxxCommonRulesEngineTest.provide_extensions(CxxCommonRulesEngineTest.java:42)

enable_common_rules(org.sonar.plugins.cxx.CxxCommonRulesEngineTest) Time elapsed: 0 sec <<< ERROR!
java.lang.IllegalStateException: Name of rule [repository=cxx, key=NotAllowedToDoTag] is empty
at org.sonar.api.server.rule.RulesDefinition$NewRule.validate(RulesDefinition.java:707)
at org.sonar.api.server.rule.RulesDefinition$NewRule.access$900(RulesDefinition.java:514)
at org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.(RulesDefinition.java:453)
at org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.(RulesDefinition.java:443)
at org.sonar.api.server.rule.RulesDefinition$Context.registerRepository(RulesDefinition.java:337)
at org.sonar.api.server.rule.RulesDefinition$Context.access$500(RulesDefinition.java:304)
at org.sonar.api.server.rule.RulesDefinition$NewRepositoryImpl.done(RulesDefinition.java:422)
at org.sonar.plugins.cxx.CxxRuleRepository.define(CxxRuleRepository.java:41)
at org.sonar.plugins.cxx.CxxCommonRulesEngineTest.enable_common_rules(CxxCommonRulesEngineTest.java:54)
—
Reply to this email directly or view it on GitHub.

jmecosta · 2015-04-04T07:35:17Z

I got that one also after using the java plugin code, and did not find any
obvious difference in the pom files. Thought it was my setup

On Sat, Apr 4, 2015, 10:05 Günter Wirth [email protected] wrote:

Hello @Bertk. After many other changes the problem has gone. Only
remaining problem seems to be CxxCommonRulesEngineTest. Problem below was
usage of obsolete @rule in all checks. I also changed this, see last
upload. Currently I'm getting NoClassDefFound and I have no glue why?

Am 03.04.2015 um 18:54 schrieb Bert [email protected]:

Hi, can you please give me some details on the compile Errors. I cannot
reproduce it (
https://github.com/Bertk/sonar-cxx/tree/use-4.5.2-API-).

I see only some failing tests …

Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.002
sec <<< FAILURE! - in org.sonar.plugins.cxx.CxxCommonRulesEngineTest
provide_extensions(org.sonar.plugins.cxx.CxxCommonRulesEngineTest) Time
elapsed: 0 sec <<< ERROR!
java.lang.IllegalStateException: Name of rule [repository=cxx,
key=NotAllowedToDoTag] is empty
at
org.sonar.api.server.rule.RulesDefinition$NewRule.validate(RulesDefinition.java:707)
at
org.sonar.api.server.rule.RulesDefinition$NewRule.access$900(RulesDefinition.java:514)
at
org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.(RulesDefinition.java:453)
at
org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.(RulesDefinition.java:443)
at
org.sonar.api.server.rule.RulesDefinition$Context.registerRepository(RulesDefinition.java:337)
at
org.sonar.api.server.rule.RulesDefinition$Context.access$500(RulesDefinition.java:304)
at
org.sonar.api.server.rule.RulesDefinition$NewRepositoryImpl.done(RulesDefinition.java:422)
at
org.sonar.plugins.cxx.CxxRuleRepository.define(CxxRuleRepository.java:41)
at
org.sonar.plugins.cxx.CxxCommonRulesEngineTest.provide_extensions(CxxCommonRulesEngineTest.java:42)

enable_common_rules(org.sonar.plugins.cxx.CxxCommonRulesEngineTest) Time
elapsed: 0 sec <<< ERROR!
java.lang.IllegalStateException: Name of rule [repository=cxx,
key=NotAllowedToDoTag] is empty
at
org.sonar.api.server.rule.RulesDefinition$NewRule.validate(RulesDefinition.java:707)
at
org.sonar.api.server.rule.RulesDefinition$NewRule.access$900(RulesDefinition.java:514)
at
org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.(RulesDefinition.java:453)
at
org.sonar.api.server.rule.RulesDefinition$RepositoryImpl.(RulesDefinition.java:443)
at
org.sonar.api.server.rule.RulesDefinition$Context.registerRepository(RulesDefinition.java:337)
at
org.sonar.api.server.rule.RulesDefinition$Context.access$500(RulesDefinition.java:304)
at
org.sonar.api.server.rule.RulesDefinition$NewRepositoryImpl.done(RulesDefinition.java:422)
at
org.sonar.plugins.cxx.CxxRuleRepository.define(CxxRuleRepository.java:41)
at
org.sonar.plugins.cxx.CxxCommonRulesEngineTest.enable_common_rules(CxxCommonRulesEngineTest.java:54)
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#435 (comment).

guwirth · 2015-04-04T08:10:16Z

@jmecosta , @Bertk , @Typz, @wenns
I'm googling and fighting with this problem for several days now. But no idea what the remaining problem is?

calling CxxCommonRulesEngineTest I get NoClassDefFound
also not possible to start plugin on the server

My feeling is

there is a extension point missing or still obsolete?
plugin contains / use still obsolete API?
dependencies in pom are missing / not up to date?

Maybe someone of you can give me a hint?

Bertk · 2015-04-04T09:16:18Z

I am not sure but did you this https://jira.codehaus.org/browse/SONAR-6162.

SQ Java plug-in has a section to set the internal key:

    for (NewRule rule : repository.rules()) {
      //FIXME: set internal key to key to ensure rule templates works properly : should be removed when SONAR-6162 is fixed.
      rule.setInternalKey(rule.key());
    }

guwirth · 2015-04-04T10:36:36Z

Yes: https://github.com/guwirth/sonar-cxx/blob/enhancement/357_45_API/sonar-cxx-plugin/src/main/java/org/sonar/plugins/cxx/CxxRuleRepository.java

Loading the rules seems to work. My feeling is that there is something wrong with CommonRulesEngine. Setting a breakpoint to doEnableRules it is not called. The method provide is crashing?

https://doEnableRulesgithub.com/guwirth/sonar-cxx/blob/enhancement/357_45_API/sonar-cxx-plugin/src/main/java/org/sonar/plugins/cxx/CxxCommonRulesEngine.java

Am 04.04.2015 um 11:16 schrieb Bert [email protected]:

I am not sure but did you this https://jira.codehaus.org/browse/SONAR-6162.

SQ Java plug-in has a section to set the internal key:
for (NewRule rule : repository.rules()) {
  //FIXME: set internal key to key to ensure rule templates works properly : should be removed when SONAR-6162 is fixed.
  rule.setInternalKey(rule.key());
}
—
Reply to this email directly or view it on GitHub.

guwirth · 2015-04-04T12:17:24Z

Ok first time green now.

aligning POM with Python plugin
integration test needs SQ >= 4.5.2 (4.5.1 is not compatible)
setting meaningful Sqale parameter for checks is open

jmecosta · 2015-04-04T14:08:01Z

What are the sqale parameters missing? The ones in the checks module should already have definition in the model

guwirth · 2015-04-04T14:14:40Z

See an example here https://github.com/guwirth/sonar-cxx/blob/enhancement/357_45_API/cxx-checks/src/main/java/org/sonar/cxx/checks/CommentedCodeCheck.java

@rule(
key = "CommentedCode",
name = "Comment should not include code",
tags = {"cxx"},
priority = Priority.BLOCKER)
@ActivatedByDefault
@SqaleSubCharacteristic(RulesDefinition.SubCharacteristics.READABILITY)
@SqaleConstantRemediation("1min")

To try things they are all READABILITY / 1min at the moment. Idea was to copy settings from Phyton checks. They have similar checks.

The ones in the checks module should already have definition in the model

Where are they defined?

Am 04.04.2015 um 16:08 schrieb Jorge Costa [email protected]:

What are the sqale parameters missing? The ones in the checks module should already have definition in the model

—
Reply to this email directly or view it on GitHub.

jmecosta · 2015-04-04T14:18:45Z

Try here
https://github.com/wenns/sonar-cxx/blob/master/sonar-cxx-plugin/src/main/resources/com/sonar/sqale/cxx-model.xml

There should be ids already there. You can have those or in the model or
via annotations, earlier it was not possible via anotations

On Sat, Apr 4, 2015, 17:14 Günter Wirth [email protected] wrote:

See an example here
https://github.com/guwirth/sonar-cxx/blob/enhancement/357_45_API/cxx-checks/src/main/java/org/sonar/cxx/checks/CommentedCodeCheck.java

@rule(
key = "CommentedCode",
name = "Comment should not include code",
tags = {"cxx"},
priority = Priority.BLOCKER)
@ActivatedByDefault
@SqaleSubCharacteristic(RulesDefinition.SubCharacteristics.READABILITY)
@SqaleConstantRemediation("1min")

To try things they are all READABILITY / 1min at the moment. Idea was to
copy settings from Phyton checks. They have similar checks.

The ones in the checks module should already have definition in the model

Where are they defined?

Am 04.04.2015 um 16:08 schrieb Jorge Costa [email protected]:

What are the sqale parameters missing? The ones in the checks module
should already have definition in the model

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#435 (comment).

guwirth · 2015-04-04T14:23:08Z

Having them directly in the Java files as annotations seems to be the best choice?
Or what are you thinking?

Am 04.04.2015 um 16:18 schrieb Jorge Costa [email protected]:

Try here
https://github.com/wenns/sonar-cxx/blob/master/sonar-cxx-plugin/src/main/resources/com/sonar/sqale/cxx-model.xml

There should be ids already there. You can have those or in the model or
via annotations, earlier it was not possible via anotations

On Sat, Apr 4, 2015, 17:14 Günter Wirth [email protected] wrote:

See an example here
https://github.com/guwirth/sonar-cxx/blob/enhancement/357_45_API/cxx-checks/src/main/java/org/sonar/cxx/checks/CommentedCodeCheck.java

@rule(
key = "CommentedCode",
name = "Comment should not include code",
tags = {"cxx"},
priority = Priority.BLOCKER)
@ActivatedByDefault
@SqaleSubCharacteristic(RulesDefinition.SubCharacteristics.READABILITY)
@SqaleConstantRemediation("1min")

To try things they are all READABILITY / 1min at the moment. Idea was to
copy settings from Phyton checks. They have similar checks.

The ones in the checks module should already have definition in the model

Where are they defined?

Am 04.04.2015 um 16:08 schrieb Jorge Costa [email protected]:

What are the sqale parameters missing? The ones in the checks module
should already have definition in the model

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#435 (comment).

—
Reply to this email directly or view it on GitHub.

jmecosta · 2015-04-04T14:40:53Z

I personally like all of them to be in one place. But either way I dont see
any issues as long as they are not defined in both places.

On Sat, Apr 4, 2015, 17:23 Günter Wirth [email protected] wrote:

Having them directly in the Java files as annotations seems to be the best
choice?
Or what are you thinking?

Am 04.04.2015 um 16:18 schrieb Jorge Costa [email protected]:

Try here

https://github.com/wenns/sonar-cxx/blob/master/sonar-cxx-plugin/src/main/resources/com/sonar/sqale/cxx-model.xml

There should be ids already there. You can have those or in the model or
via annotations, earlier it was not possible via anotations

On Sat, Apr 4, 2015, 17:14 Günter Wirth [email protected]
wrote:

See an example here

https://github.com/guwirth/sonar-cxx/blob/enhancement/357_45_API/cxx-checks/src/main/java/org/sonar/cxx/checks/CommentedCodeCheck.java

@rule(
key = "CommentedCode",
name = "Comment should not include code",
tags = {"cxx"},
priority = Priority.BLOCKER)
@ActivatedByDefault
@SqaleSubCharacteristic(RulesDefinition.SubCharacteristics.READABILITY)
@SqaleConstantRemediation("1min")

To try things they are all READABILITY / 1min at the moment. Idea was
to
copy settings from Phyton checks. They have similar checks.

The ones in the checks module should already have definition in the
model

Where are they defined?

Am 04.04.2015 um 16:08 schrieb Jorge Costa <[email protected]
:

What are the sqale parameters missing? The ones in the checks module
should already have definition in the model

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#435 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#435 (comment).

- mark deprecated API usage - replace RuleRepository with RulesDefinition (http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.sonar/sonar-plugin-api/4.5.2/org/sonar/api/server/rule/RulesDefinition.java#RulesDefinition) - replace XMLRuleParser with RulesDefinitionXmlLoader (http://javadocs.sonarsource.org/4.4/apidocs/org/sonar/api/server/rule/RulesDefinitionXmlLoader.html) - update unit tests according to: - https://github.com/SonarSource/sonarqube/blob/branch-4.3/plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/rule/XooRulesDefinition.java - https://github.com/SonarSource/sonarqube/blob/branch-4.3/plugins/sonar-xoo-plugin/src/test/java/org/sonar/xoo/rule/XooRulesDefinitionTest.java - convert checks to new format - set Sqale values in Java files - Migrate text colorizing to use Highlightable interface: https://jira.codehaus.org/browse/SONARJS-379 - using JavaScript as base: https://github.com/SonarCommunity/sonar-javascript/tree/master/sonar-javascript-plugin/src/main/java/org/sonar/plugins/javascript/highlighter Hints: - needs SQ 4.5.2 or later for testing - needs Java 1.6 or later

guwirth · 2015-04-08T16:05:36Z

Migrate text colorizing to use Highlightable interface: https://jira.codehaus.org/browse/SONARJS-379

using JavaScript as base: https://github.com/SonarCommunity/sonar-javascript/tree/master/sonar-javascript-plugin/src/main/java/org/sonar/plugins/javascript/highlighter

- set C++ comment style in highlighter

4.5.2 API

guwirth · 2015-04-25T19:53:00Z

documented: https://github.com/wenns/sonar-cxx/wiki/Extending-the-code-analysis

guwirth added the enhancement label Apr 5, 2015

guwirth self-assigned this Apr 5, 2015

guwirth added this to the M 0.9.3 milestone Apr 5, 2015

guwirth added 2 commits April 8, 2015 18:26

set parsing error check to INSTRUCTION_RELIABILITY

133e617

- try to set tags for checks

0806600

- set C++ comment style in highlighter

guwirth added a commit that referenced this pull request Apr 9, 2015

Merge pull request #435 from guwirth/enhancement/357_45_API

3698ac5

4.5.2 API

guwirth merged commit 3698ac5 into SonarOpenCommunity:master Apr 9, 2015

guwirth deleted the enhancement/357_45_API branch April 14, 2015 10:19

guwirth mentioned this pull request Apr 17, 2015

Name of rule [repository=cxx, key=MissingInclude] is empty #460

Closed

guwirth added the docu request label Apr 21, 2015

guwirth removed the docu request label Apr 25, 2015

4.5.2 API #435

4.5.2 API #435

Conversation

guwirth commented Mar 1, 2015

jmecosta commented Mar 2, 2015

guwirth commented Mar 2, 2015

jmecosta commented Mar 2, 2015

jmecosta commented Mar 2, 2015

guwirth commented Mar 2, 2015

guwirth commented Mar 2, 2015

jmecosta commented Mar 2, 2015

guwirth commented Mar 2, 2015

jmecosta commented Mar 2, 2015

guwirth commented Mar 3, 2015

jmecosta commented Mar 3, 2015

guwirth commented Mar 3, 2015

jmecosta commented Mar 3, 2015

wenns commented Mar 3, 2015

jmecosta commented Mar 4, 2015

Compiling against the 4.5 API: yes, the rule repositories should be reworked. AFAIR, sonar-php can be looked at for examples how to do that.

guwirth commented Mar 4, 2015

guwirth commented Mar 22, 2015

guwirth commented Apr 2, 2015

guwirth commented Apr 2, 2015

guwirth commented Apr 2, 2015

jmecosta commented Apr 2, 2015

guwirth commented Apr 3, 2015

jmecosta commented Apr 3, 2015

guwirth commented Apr 3, 2015

Bertk commented Apr 3, 2015

guwirth commented Apr 4, 2015

jmecosta commented Apr 4, 2015

guwirth commented Apr 4, 2015

Bertk commented Apr 4, 2015

guwirth commented Apr 4, 2015

guwirth commented Apr 4, 2015

jmecosta commented Apr 4, 2015

guwirth commented Apr 4, 2015

jmecosta commented Apr 4, 2015

guwirth commented Apr 4, 2015

jmecosta commented Apr 4, 2015

guwirth commented Apr 8, 2015

guwirth commented Apr 25, 2015

Compiling against the 4.5 API: yes, the rule repositories should be
reworked. AFAIR, sonar-php can be looked at for examples how to do that.