[core] Add new Metrics Report Format #5166
Conversation
|
Thanks for the contribution. Unfortunately, I don't think this is the right approach to exposing raw metric values…
Exposing raw metrics has never been a goal for PMD, so if we were to do this, we would have to think about a more organic approach… |
|
Do you have a concrete idea on how to implement this so that it better fits into the existing PMD structure? From an architectural standpoint, I understand that it would be cleaner if we would report metrics by using PMD as a library that is invoked by some other tool. Our approach was a pragmatic idea on how to reuse all the existing "infrastructure" elements (maven, groovy plugins, etc.) without duplicating those elements in an additional tool. |
|
That's probably the result of the discussion earlier this year in the chat: Quoting it here for reference:
|
|
Thanks for resurrecting this old thread! I think the non-invasive implementation of @maxwai is (in a way) such an abstraction that you mentioned. We have a new interface that marks all rules that can produce metrics. These rules are also visible as violation rules, is this the problem you are seeing? Should the new metrics rules form a new hierarchy that stands side by side with the existing one? |
|
I'm guessing now, but I see these potential issues: With this solution, you would call PMD on CLI e.g. with The problem is, that we don't find violations now, we calculate metrics. That's why maybe a different command for the CLI interface is better, so that you can't mess up: These changes would hide the implementation of this metrics solution and the only supported entry point from CLI would be via Introducing |
|
I see, the current approach has several drawbacks. But touching the maven plugin is something I wanted to avoid. When we need to change it as well then we need to touch the Gradle plugin, etc. Maybe then it would be cleaner to write a new and simple maven plugin, that generates metrics by using PMD? I've seen that you are located in Munich as well: Would it make sense to set up a meeting somewhere in the city (or in the university of applied sciences) to discuss the topic? |
I think, the easiest way for you currently would be, to create a library, that contains the rules, that produce the metrics and the special metrics formatter. This can be added as an additional dependency to the maven-pmd-plugin/gradle, just like ordinary custom rules (see https://maven.apache.org/plugins/maven-pmd-plugin/examples/multi-module-config.html for the example with a "build-tools" module/library). Using all this doesn't work out of the box anyway - if I understand this correctly: When a project wants to use Jenkins and use your Jenkins Plugin to display metrics reports/graphs, then the project needs to first add maven-pmd-plugin (or gradle pmd plugin), configure it to run the special metrics ruleset and use the special metrics formatter. If the project already uses PMD, then it needs to configure an additional/separate PMD execution. Ok, I've read now on https://github.com/jenkinsci/metrics-aggregation-plugin that this Jenkins plugin provides a post-build-step, that actually seems to call PMD... which is for Java a bit tricky, as it must calculate the correct project classpath for analysis (the auxiliary classpath) which you get for free from the build tools.
Maybe that could help. We could outline a bit more concretely what would need to be done for a long term solution ("proper solution" - that involves changing PMD, maven-pmd-plugin and potentially other parts) and what could be done for a short-term solution. Update: related PR: jenkinsci/coverage-plugin#213 |
Describe the PR
This adds a new xml report format, used to show metrics of the project. This new format will be used by the jenkins coverage-plugin.
Currently 4 Metrics are in the default ruleset:
For now only these 4 are added as a proof of concept but more can be added in the future.
No new metric is added, every metrics was already calculated in another rule but is now explicitly exported as a metric.
To be able to distinguish between normal Violations and Metrics, a new Interface
MetricRulewas created. This Interface provides a way to pass the necessary information to the renderer by putting them in the violation description and then reading them back out. This is open to discussion if there is a better way to do this without rewriting a lot of the core architecture.Also open to discussion is the location of the XSD file for the report. Strictly speaking it is not necessary but maybe it is wanted.
Ready?
./mvnw clean verifypasses (checked automatically by github actions)