RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/pmd/pmd/issues/3902 below:

[core] Violation decorators · Issue #3902 · pmd/pmd · GitHub

Is your feature request related to a problem? Please describe.

Currently violations have a couple of methods like getPackageName, getMethodName:

/** * Get the package name of the Class in which this violation was identified. * * @return The package name. */ // TODO Isn't this Java specific? String getPackageName(); /** * Get the name of the Class in which this violation was identified. * * @return The Class name. */ // TODO Isn't this Java specific? String getClassName(); /** * Get the method name in which this violation was identified. * * @return The method name. */ // TODO Isn't this Java specific? String getMethodName(); /** * Get the variable name on which this violation was identified. * * @return The variable name. */ String getVariableName();

These are mostly Java-specific and the way this data is filled-in is very awkward: we have a JavaRuleViolation subclass of RuleViolation that initializes the fields in its constructor. To create a JavaRuleViolation we need a RuleViolationFactory instance which is mostly redundant.

The problems with this design are

We need a subclass of ParametricRuleViolation even though the superclass already has all fields
We need the interface RuleViolationFactory and language-specific implementations even though they're only used to call the correct constructor for the violation subclass
The attributes cannot be extended easily by other languages than Java
The attributes are meaningless in some languages, eg XML flavours

Describe the solution you'd like

Refactor these "extra attributes" to be exposed through a method Map<String, String> getAdditionalInfo() in RuleViolation. Standard keys like PACKAGE_NAME and CLASS_NAME can be exposed as constants in the RuleViolation interface.
Create a new interface ViolationDecorator whose job is to add extra attributes to the map. Use that in RuleContext when we create a new violation
Remove the RuleViolation subclasses and finally remove RuleViolationFactory.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context

Part of PMD 7 PMD 7 Tracking Issue #3898
The new interface would be part of the nspmd.reporting package, like ViolationSuppressor
The extra attributes are constrained to be string-valued because we need to serialize them to write them into the violation cache.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4