After more thinking I don’t think this is a good idea anymore :) See https://github.com/revapi/revapi/issues/29#issuecomment-200329495 I’m pasting it here: " 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 “ So I’m going to close the jira issue I created for this at http://jira.xwiki.org/browse/XCOMMONS-947 WDYT? Thanks -Vincent
On 23 Mar 2016, at 13:17, Vincent Massol <[email protected]> wrote:
On 23 Mar 2016, at 13:10, Vincent Massol <[email protected]> wrote:
On 23 Mar 2016, at 12:33, Marius Dumitru Florea <[email protected]> wrote:
On Wed, Mar 23, 2016 at 12:36 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’ve been thinking about how to improve our release process regarding the backward compat checks (we were using clirr for this and now revapi).
In short the idea is:
* Store the revapi config (containing the list of breakages to ignore) in a wiki page on xwiki.org, associated with a given release note. For example in ReleaseNotes.BackwardCompatibilityForXWiki${xwiki.version.major}${xwiki.version.minor} (using http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html) * Configure our build to download that json file and store it in target/ for revapi, see https://github.com/revapi/revapi/issues/31#issuecomment-200286810
* Work on making it not fail the build when offline (see https://github.com/revapi/revapi/issues/31#issuecomment-200286810)
download-maven-plugin is caching the downloaded files by default (I'm using it to download the CKEditor sources only once). I guess we won't be able to use this feature because the revapi config can be modified multiple times during a release dev. Unless we modify the URL in the pom whenever we modify the wiki page (instead of modifying the URL only after each release).
Yes this is why on https://github.com/revapi/revapi/issues/31#issuecomment-200286810 I have:
<skip>${xwiki.revapi.offline}</skip> <skipCache>${xwiki.revapi.cache}</skipCache>
By default it’s set to “true”. The idea is to use true when in offline mode.
ATM this can be done with this: mvn clean install … -Dxwiki.revapi.offline=true -Dxwiki.revapi.cache=true
I meant you could use the following when offline if you have run the check before: mvn clean install … -Dxwiki.revapi.cache=true
Thanks -Vincent
I’m trying to find ways to do that automatically when maven is in offline mode so that running the following would be enough: mvn clean install -o
See https://twitter.com/vmassol/status/712585195581521920
* Write some groovy script in the release notes template page to
automatically generate the “API Breakage” section from the parsed json from ReleaseNotes.BackwardCompatibilityForXWiki${xwiki.version.major}${xwiki.version.minor}
WDYT?
Sound good. I'm only worried about the offline build issue.
Yep, me too. Being offline is not going to be an issue since I don’t believe we need to run revapi when offline most of the time and with the cached file it would work most of the time too.
However I’m more worried about the times when - xwiki.org is down. - when the user is behind a proxy
However with the “failOnError” property from https://github.com/maven-download-plugin/maven-download-plugin/issues/48 that we could set to false, we should be able to make it work. Of course, we’ll need to also skip the revapi plugin when the config file isn’t present.
All in all it would be much easier if revapi were to implement https://github.com/revapi/revapi/issues/31 and I don’t think it’s too difficult to do.
So in conclusion I still need to figure out a few little details but it looks like this could improve a lot our RM work since there wouldn’t be anything to do from the RM POV :)
Thanks -Vincent
Thanks, Marius
Thanks -Vincent