[sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Freddy Mallet SonarSource
Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Alexandre Victoor-2
Hello all
Thanks Freddy for this overview. I have already done a while ago some tests with sonar 2.3.M1. 
Do you know if a M2 version will be available soon ? 
Otherwise, do you consider current trunk version stable enough to perform some tests ?
Anyway thanks for this new promising API.
Kind regards

Alex


On Mon, Sep 27, 2010 at 9:41 PM, Freddy Mallet <[hidden email]> wrote:
Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Freddy Mallet SonarSource
Hi Alex,

The trunk is really pretty stable but anyway a 2.3 RC1 will be released this week !

In fact, I'm just a user of the Sonar API and Simon is the father :-)

cheers,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------


On Mon, Sep 27, 2010 at 10:11 PM, Alexandre Victoor <[hidden email]> wrote:
Hello all
Thanks Freddy for this overview. I have already done a while ago some tests with sonar 2.3.M1. 
Do you know if a M2 version will be available soon ? 
Otherwise, do you consider current trunk version stable enough to perform some tests ?
Anyway thanks for this new promising API.
Kind regards

Alex


On Mon, Sep 27, 2010 at 9:41 PM, Freddy Mallet <[hidden email]> wrote:
Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Alexandre Victoor-2
Then thanks Simon for the new API ;)
I will try to perform some tests this week and give you some feedback asap.
Regards

Alex

On Mon, Sep 27, 2010 at 10:29 PM, Freddy Mallet <[hidden email]> wrote:
Hi Alex,

The trunk is really pretty stable but anyway a 2.3 RC1 will be released this week !

In fact, I'm just a user of the Sonar API and Simon is the father :-)

cheers,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------


On Mon, Sep 27, 2010 at 10:11 PM, Alexandre Victoor <[hidden email]> wrote:
Hello all
Thanks Freddy for this overview. I have already done a while ago some tests with sonar 2.3.M1. 
Do you know if a M2 version will be available soon ? 
Otherwise, do you consider current trunk version stable enough to perform some tests ?
Anyway thanks for this new promising API.
Kind regards

Alex


On Mon, Sep 27, 2010 at 9:41 PM, Freddy Mallet <[hidden email]> wrote:
Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------



Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Akram Ben Aissi
In reply to this post by Freddy Mallet SonarSource
Hello Freddy,

it seems that the ruleset XML files now must contain mandatory attributes:

<profile>
  <name>Php_CodeSniffer default profile</name>
  <language>php</language>
  <rules>
....

Otherwise I got a null pointer exception when hibernate tries to persit the rules.

Greetings

Akram Ben Aïssi

Akram Ben Aïssi
Consultant

[hidden email]

 



Freddy Mallet a écrit :
Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Freddy Mallet SonarSource
Thanks Akram for this feedback !

Simon, I guess we should generate a meaningful error exception when those two nodes (name and language) are not provided.

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------


On Tue, Sep 28, 2010 at 11:33 AM, Akram BEN AISSI <[hidden email]> wrote:
Hello Freddy,

it seems that the ruleset XML files now must contain mandatory attributes:

<profile>
  <name>Php_CodeSniffer default profile</name>
  <language>php</language>
  <rules>
....

Otherwise I got a null pointer exception when hibernate tries to persit the rules.

Greetings

Akram Ben Aïssi
Consultant

[hidden email]

 



Freddy Mallet a écrit :
Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Simon Brandhof
Thanks for the feedback Akram. It's fixed now. A better explanation is logged when the mandatory nodes <name> and <language> are missing.


On Tue, Sep 28, 2010 at 12:42 PM, Freddy Mallet <[hidden email]> wrote:
Thanks Akram for this feedback !

Simon, I guess we should generate a meaningful error exception when those two nodes (name and language) are not provided.

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------


On Tue, Sep 28, 2010 at 11:33 AM, Akram BEN AISSI <[hidden email]> wrote:
Hello Freddy,

it seems that the ruleset XML files now must contain mandatory attributes:

<profile>
  <name>Php_CodeSniffer default profile</name>
  <language>php</language>
  <rules>
....

Otherwise I got a null pointer exception when hibernate tries to persit the rules.

Greetings

Akram Ben Aïssi
Consultant

[hidden email]

 



Freddy Mallet a écrit :
Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Matthijs Galesloot
In reply to this post by Freddy Mallet SonarSource
Hi Freddy

I am in the process of migrating the rules of the web plugin to the Sonar API of 2.3. 

Multiple rules can be configured in the rules profile for the same rule definition. The user can configure parameters of the rule. It would make sense if the user can also configure name, description and priority. This seems not be possible with the 2.3 API. 

E.g. checkstyle has the following rule definition: com.puppycrawl.tools.checkstyle.checks.regexp.RegexpMultilineCheck. It would be nice to instantiate this rule definition multiple times with a different name and description. The will be useful in the violation reports.  
In the web plugin is a rule IllegalElement. I would like to instantiate this rule multiple times, and provide different messages to the rule instantiations. 

Matthijs 

2010/9/27 Freddy Mallet <[hidden email]>
Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Simon
Administrator
Hi Matthijs,

If your rules are defined in a XML file, you should add the following to the node <rule> :
<cardinality>MULTIPLE</cardinality>

If they are defined with the annotation @org.sonar.check.Rule, then you should use the field cardinality = MULTIPLE. This field has been added after 2.3-RC2, so you have to wait for next RC or final release.

The main limitation is that the rule definition can be used to create new rules only from UI (see the button "Copy rule" in the Checkstyle rule "Illegal Regexp"). I don't think that it's possible to hardcode new rules directly from plugins.

Regards,
Simon


On Sun, Oct 10, 2010 at 4:59 PM, Matthijs Galesloot <[hidden email]> wrote:
Hi Freddy

I am in the process of migrating the rules of the web plugin to the Sonar API of 2.3. 

Multiple rules can be configured in the rules profile for the same rule definition. The user can configure parameters of the rule. It would make sense if the user can also configure name, description and priority. This seems not be possible with the 2.3 API. 

E.g. checkstyle has the following rule definition: com.puppycrawl.tools.checkstyle.checks.regexp.RegexpMultilineCheck. It would be nice to instantiate this rule definition multiple times with a different name and description. The will be useful in the violation reports.  
In the web plugin is a rule IllegalElement. I would like to instantiate this rule multiple times, and provide different messages to the rule instantiations. 

Matthijs 

2010/9/27 Freddy Mallet <[hidden email]>

Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Matthijs Galesloot
Hi Simon

I checked the Quality profiles in Sonar. The new copy editor is really nice. 

I am not sure yet about profile import/export. I think copied rules do not appear in exported profiles. 
E.g. 
- Copy the Sun checks profile to a new profile. 
- In the new profile, copy the RegExp check to a new Check 
- Backup the new profile to XML file
Expected: xml contains the copied Check
Actual: xml did not contain the copied Check

Regards
Matthijs 

2010/10/11 Simon Brandhof <[hidden email]>
Hi Matthijs,

If your rules are defined in a XML file, you should add the following to the node <rule> :
<cardinality>MULTIPLE</cardinality>

If they are defined with the annotation @org.sonar.check.Rule, then you should use the field cardinality = MULTIPLE. This field has been added after 2.3-RC2, so you have to wait for next RC or final release.

The main limitation is that the rule definition can be used to create new rules only from UI (see the button "Copy rule" in the Checkstyle rule "Illegal Regexp"). I don't think that it's possible to hardcode new rules directly from plugins.

Regards,
Simon



On Sun, Oct 10, 2010 at 4:59 PM, Matthijs Galesloot <[hidden email]> wrote:
Hi Freddy

I am in the process of migrating the rules of the web plugin to the Sonar API of 2.3. 

Multiple rules can be configured in the rules profile for the same rule definition. The user can configure parameters of the rule. It would make sense if the user can also configure name, description and priority. This seems not be possible with the 2.3 API. 

E.g. checkstyle has the following rule definition: com.puppycrawl.tools.checkstyle.checks.regexp.RegexpMultilineCheck. It would be nice to instantiate this rule definition multiple times with a different name and description. The will be useful in the violation reports.  
In the web plugin is a rule IllegalElement. I would like to instantiate this rule multiple times, and provide different messages to the rule instantiations. 

Matthijs 

2010/9/27 Freddy Mallet <[hidden email]>

Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------



Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Sonar 2.3 : Here are what has changed in the Sonar Rule API

Simon
Administrator
Which version of sonar did you test ? I can't reproduce the pb on 2.3. I confirm that the new rule could be exported and imported.


On Tue, Oct 12, 2010 at 8:18 AM, Matthijs Galesloot <[hidden email]> wrote:
Hi Simon

I checked the Quality profiles in Sonar. The new copy editor is really nice. 

I am not sure yet about profile import/export. I think copied rules do not appear in exported profiles. 
E.g. 
- Copy the Sun checks profile to a new profile. 
- In the new profile, copy the RegExp check to a new Check 
- Backup the new profile to XML file
Expected: xml contains the copied Check
Actual: xml did not contain the copied Check

Regards
Matthijs 

2010/10/11 Simon Brandhof <[hidden email]>

Hi Matthijs,

If your rules are defined in a XML file, you should add the following to the node <rule> :
<cardinality>MULTIPLE</cardinality>

If they are defined with the annotation @org.sonar.check.Rule, then you should use the field cardinality = MULTIPLE. This field has been added after 2.3-RC2, so you have to wait for next RC or final release.

The main limitation is that the rule definition can be used to create new rules only from UI (see the button "Copy rule" in the Checkstyle rule "Illegal Regexp"). I don't think that it's possible to hardcode new rules directly from plugins.

Regards,
Simon



On Sun, Oct 10, 2010 at 4:59 PM, Matthijs Galesloot <[hidden email]> wrote:
Hi Freddy

I am in the process of migrating the rules of the web plugin to the Sonar API of 2.3. 

Multiple rules can be configured in the rules profile for the same rule definition. The user can configure parameters of the rule. It would make sense if the user can also configure name, description and priority. This seems not be possible with the 2.3 API. 

E.g. checkstyle has the following rule definition: com.puppycrawl.tools.checkstyle.checks.regexp.RegexpMultilineCheck. It would be nice to instantiate this rule definition multiple times with a different name and description. The will be useful in the violation reports.  
In the web plugin is a rule IllegalElement. I would like to instantiate this rule multiple times, and provide different messages to the rule instantiations. 

Matthijs 

2010/9/27 Freddy Mallet <[hidden email]>

Hi Guys,

With this email, I'd like to give you a quick overview of the changes in the Sonar Rule API between version 2.2 and upcoming version 2.3. 

The first most important thing is that the old Rule API has just been deprecated (and has moved to the sonar-deprecated plugin), so Sonar 2.3 is fully backward compatible with all plugins written for Sonar 2.X. 

The old Rule API had several drawbacks (see the CheckstyleRulesRepository in Sonar 2.2 [1]) :
  • It was impossible to define several rule engines in the same Sonar plugin
  • The Single Responsibility Principle was violated by each rule engine as the rule engine classes were in charge to :
    • Declare a new repository of rules
    • Implement the mechanism to import an external configuration file
    • Implement the mechanism to export a configuration file
    • Declare all default profiles
  • Moreover the RulesManager class provided too many methods whereas this class was used 99% of the time to simply retrieve a Rule 
With Sonar 2.3, all those drawbacks have been removed :
  • The key of a rule repository is no more the key of the plugin
  • There is one extension point by responsibility
  • There is a user-friendly RuleFinder [2] to find rules
For instance, here is what has been done to migrate the Sonar Checkstyle plugin from the old to the new Sonar Rule API :
  1. Creation of a CheckstyleRuleRepository [3] which extends RuleRepository (Mandatory) to declare all the checkstyle rules with the standard Sonar XML format. Have a look to the first line of the constructor : super(CheckstyleConstants.REPOSITORY_KEY, Java.KEY);
  2. Creation of a CheckstyleProfileExporter [4] which extends ProfileExporter (Optional) to be able to generate the Checkstyle configuration file from a quality profile
  3. Creation of a CheckstyleProfileImporter [5] which extends ProfileImporter (Optional) to be able to create a new quality profile from the Sonar web interface by importing a Checkstyle configuration file. When something goes wrong during the import step (a rule key is unknown, the XML format is wrong, ...), a new ValidationMessage can be fed to display all warnings and errors in the Sonar web interface
  4. Creation of a SonarWayProfile [6], SonarWayWithFindbugsProfile (Optional) and SunConventionsProfile with extend XMLProfileDefinition to easily define some default quality profiles
  5. Replace the use of the RulesManager by the RuleFinder [2]
  6. Suppression of the the old CheckstyleRulesRepository [1]
The migration is in fact pretty straightforward. I've migrated the PMD, Checkstyle and Findbugs plugins to this new API so if you have any question I'll be happy to help you.

regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
www.SonarSource.com
----------------------------------------