Allow a checker to be configured multiple times

[sdibernardo]

Thoughts:

• ParentRuleSet -> local RuleSet (change how inheriting works?)
• Declare Checker and provide multiple locations (different classes with different checks?)

Especially for bigger projects, where multiple subprojects might inherit from the same parent ruleset, the local ruleset will overwrite rules that are defined multiple times. Instead of overwriting, merging might be the more intuitive approach here. Additionally, per checker, multiple configurations should be allowed and configurable (extend XML).

Thoughts? @fkoehne @sebastiansirch @cl-a-us

[fkoehne]

Thanks @sebastiansirch for the idea.
What about this approach:

<rule>
		<name>My Ruthless ProcessVariablesNameConventionChecker</name>
                <class>ProcessVariablesNameConventionChecker</class>
		<state>false</state>
                    <elementConventions>
                       ....

Spring XML configurations worked similarly.

The name element could be optional, i.e. it is assumed to be the classname unless you have a reason to provide a separate name. The primary reason would be to have the same checker twice with different configurations.

[sebastiansirch]

Regarding inheritance etc., I would prefer to keep things simple: When the child rule set has a rule configured with the same name/id than the parent rule set, the child rule overrides the parent rule completely (without merging any attributes of the rule configuration)

[sdibernardo]

@fkoehne That approach looks clean and could be implemented reusing existing logic.

Regarding inheritance etc., I would prefer to keep things simple: When the child rule set has a rule configured with the same name/id than the parent rule set, the child rule overrides the parent rule completely (without merging any attributes of the rule configuration)

This behaviour is the default case right now. Will still look into it to reassure that it works properly in all cases.

[sdibernardo]

What about something like this?

<rule name="test12">
	<name>JavaDelegateChecker</name>
	<settings>
		<setting></setting>
	</settings>
	<state>true</state>
</rule>
<rule name="test34">
	<name>JavaDelegateChecker</name>		
	<settings>
		<setting></setting>
	</settings>
	<state>true</state>
</rule>

This allows a checker to be configured as often as desired. The logic to instantiate a checker would then change obviously, but I imagine this to be quite intuitive. Does that reflect the need in practice? Inheritance would then work based on the specified rule name as it already does. Any thoughts?
@fkoehne @sebastiansirch

[fkoehne]

Works for me.

[sebastiansirch]

<name>JavaDelegateChecker</name>

Yes, although I think it is a bit confusing to use <name> when refering to a Java class or concrete implementation. I would expect something like "className" or "implementation" here.

<name> is usually something descriptive, something I can choose more freely, use spaces, special characters etc.; But when this breaks backward compatibility, we should better not change it.

Regarding the new attribute within the rule tag, I would prefer to use "id" over using "name" for a second time, i.e.:
<rule id="test34">

Then the logic would be to use "name" as a reference to a checker implementation whereas each instantiation is a rule with a unique "id".