Aggregated plain text report for copy-pasting in release notes about revapi HOT 6 CLOSED

That is a good idea.

Currently, I think revapi could get you half way there.. You can "externalize" your API changes into a separate revapi configuration file (you'd configure revapi along the lines of http://revapi.org/modules/revapi-maven-plugin/examples/multi-file-configuration.html and put your API changes in a separate config file like https://github.com/revapi/revapi/blob/5ccf3788a09a015b927fea97abe14e7265642ddc/revapi-java-spi/api-changes.json). You could then write a simple script that would parse them and create a text report.

The revapi:report goal is very rudimentary right now but I think it could or maybe even should be used for this purpose. I'll think about some way we could get there.

Btw. I'm not very experienced in writing maven plugins and even less in writing reporting plugins. It'd be great if you could share some experience with writing or using them so that the end result is usable.

from revapi.

The NPE comes from the fact that for the report to work, you need to have your artifacts built. So I hope that mvn clean package revapi:report should work.

The error reporting could be improved, I admit ;)

from revapi.

FTR I'm hesitating between 2 routes:

• Implementing http://jira.xwiki.org/browse/XCOMMONS-947
• Continuing in the direction of this issue, i.e.
  ** Generate an aggregated plain text report for all modules (this issue)
  ** Publish it to an xwiki.org page using some maven http plugin (or an ant task) using the XWiki REST API

This other route is probably better since it:

• Keeps the config versioned in the SCM, close to the code
• Doesn't have any offline issue and xwiki can be built and have backward-compat checks done while offline

from revapi.

I've stopped hesitating, this is the best way.

from revapi.

Btw. I'm not very experienced in writing maven plugins and even less in writing reporting plugins. It'd be great if you could share some experience with writing or using them so that the end result is usable.

What I'd do:

• In the check mojo:
  ** Add a mojo parameter to configure a file where to also output the violations. If this file already exists, there could a config option to append to it, or replace it. This would allow to have all violations in a single file.
  ** Add a mojo parameter to ignore some excludes from the revapi configuration. Since you consider config as a black box from the POV of the maven plugin, you'd need to add an option in the java api of revapi for that I guess. Now this parameter would need to explicit mention which path in the json to ignore (since we want to not ignore the default excludes we have in XWiki for example ;)).
  ** The user would execute the check mojo with a single location specified and with ignoring the custom excludes in order to generate an output for the expected violations.
• In the report mojo:
  ** Add a parameter to specify the location of a violation output file (the one generated from the check mojo). This would be the input for the report mojo
  ** Add a parameter to specify which reports to generate: html, text

WDYT?

from revapi.

I think this is doable now with report-aggregate goal and a custom template for text reporter configured to append to output.

from revapi.