Services like Codacy, Coveralls, CodeCov, etc. are all really nice, but for simple projects, it's kinda annoying to have to set them up for basic reporting. They're really best suited for large, fast-moving projects, but for small OSS projects I find it can be just a bit overkill. It would be nice if Orchid could read the reports for code coverage, test results, quality checks, etc. and create pages to display those reports, instead of passing those reports to other services.
In addition, it would be really awesome to connect these reports to the code documentation plugins. Imaging a single report with all code coverage metrics, but having a single class's coverage displayed on that class's documentation page.
I would welcome any thoughts, suggestions, or desired features that anyone has for this feature.
Requirements
A new plugin, maybe OrchidCodeReports, which has everything in it to scan the project and find the build-tool-generated reports. It probably doesn't make sense to have Orchid actually run those reports itself, as it would start to require full classpath management, etc.
Features
ReportsGenerator: a Generator to create pages for each report. A "report" is akin to a wiki section, blog post category, etc. in that it may consist of many pages, and each one is configured individually. Should 100% definitely also generate standalone SVG badges, which can be added to the project README, and can have their colors and text customized.
ReportAdapter interface: similar to the WikiAdapter, be able to customize the type of report generated for each report. Example adapters: codeCoverage (jacoco), testResults (gradle XML reports), codeStyle (checkstyle XML), apiDiff (japicmp) etc. They might need to be made more specific to the actual tools used (gradleCodeCoverage, jacocoCodeCoverage, etc.), or it might have different interface adapters for finding/parsing/interpreting build reports.
ReportComponent: Used to add report metrics to code documentation pages. Should ideally be added through the Archetype, and is able to automatically make the connection between the doc ID (e.g. the current class page) and the relevant report metrics. Can be configured to only show a specific report.
ReportMenu: Generates a menu that links to all individual reports. Can be configured to only show a specific report.
This will be included in the OrchidDocs bundle.
Dependencies
This plugin will loosely depend on the refactoring updates to code doc generation, #232, currently underway. The updates there will create a consistent interface across all code-doc plugins, and that known structure will be exploited by this plugin to create the links between reports and class pages. It is, however, like all plugin projects, completely independent of that connection, and can even work perfectly well if you choose not to include any code documentation in your Orchid build. The classes referenced in the reports simply will not have anything to link to, and text will be displayed statically, without a link.
Description
Services like Codacy, Coveralls, CodeCov, etc. are all really nice, but for simple projects, it's kinda annoying to have to set them up for basic reporting. They're really best suited for large, fast-moving projects, but for small OSS projects I find it can be just a bit overkill. It would be nice if Orchid could read the reports for code coverage, test results, quality checks, etc. and create pages to display those reports, instead of passing those reports to other services.
In addition, it would be really awesome to connect these reports to the code documentation plugins. Imaging a single report with all code coverage metrics, but having a single class's coverage displayed on that class's documentation page.
I would welcome any thoughts, suggestions, or desired features that anyone has for this feature.
Requirements
A new plugin, maybe
OrchidCodeReports, which has everything in it to scan the project and find the build-tool-generated reports. It probably doesn't make sense to have Orchid actually run those reports itself, as it would start to require full classpath management, etc.Features
ReportsGenerator: a Generator to create pages for each report. A "report" is akin to a wiki section, blog post category, etc. in that it may consist of many pages, and each one is configured individually. Should 100% definitely also generate standalone SVG badges, which can be added to the project README, and can have their colors and text customized.ReportAdapterinterface: similar to theWikiAdapter, be able to customize the type of report generated for each report. Example adapters:codeCoverage(jacoco),testResults(gradle XML reports),codeStyle(checkstyle XML),apiDiff(japicmp) etc. They might need to be made more specific to the actual tools used (gradleCodeCoverage,jacocoCodeCoverage, etc.), or it might have different interface adapters for finding/parsing/interpreting build reports.ReportComponent: Used to add report metrics to code documentation pages. Should ideally be added through the Archetype, and is able to automatically make the connection between the doc ID (e.g. the current class page) and the relevant report metrics. Can be configured to only show a specific report.ReportMenu: Generates a menu that links to all individual reports. Can be configured to only show a specific report.OrchidDocsbundle.Dependencies
This plugin will loosely depend on the refactoring updates to code doc generation, #232, currently underway. The updates there will create a consistent interface across all code-doc plugins, and that known structure will be exploited by this plugin to create the links between reports and class pages. It is, however, like all plugin projects, completely independent of that connection, and can even work perfectly well if you choose not to include any code documentation in your Orchid build. The classes referenced in the reports simply will not have anything to link to, and text will be displayed statically, without a link.