Bug 60134 - Enhance Jenkins CI to run clirr/japicmp on the nightly builds to find API-breakage earlier
Summary: Enhance Jenkins CI to run clirr/japicmp on the nightly builds to find API-bre...
Alias: None
Product: POI
Classification: Unclassified
Component: POI Overall (show other bugs)
Version: 3.15-dev
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Reported: 2016-09-14 19:41 UTC by Dominik Stadler
Modified: 2016-11-18 06:08 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Stadler 2016-09-14 19:41:37 UTC
For 3.15 we did find some breaking changes only very late in the release-cycle. We should use some API-checker/comparison tool as part of the CI runs to detect such changes earlier.

See e.g. https://github.com/siom79/japicmp
The tool at http://clirr.sourceforge.net/ looks to be abandoned.
Comment 1 Dominik Stadler 2016-09-14 20:03:08 UTC
Another tool in this area is http://revapi.org/
Comment 2 Dominik Stadler 2016-09-18 16:26:50 UTC
See https://builds.apache.org/view/POI/job/POI-API-Check/ for an initial try at a CI config which performs API comparison with a previous version of POI. 

I selected japicmp because clirr seems to be dormant and revapi was complicated to start on the commandline without actual maven build...

I will work some more on it to put this into the build.xml so developers can run it locally as well.
Comment 3 Dominik Stadler 2016-10-14 21:19:50 UTC
I have now added an initial version of adding tasks for japicmp to the Gradle build via r1764960, this is not yet perfect, but is an initial attempt at providing this. 

https://github.com/melix/japicmp-gradle-plugin/issues/6 asked for a release of the Gradle plugin for japicmp to use some not-yet released features, it was quickly resolved by the author, but is not yet visible and thus not used in the build.gradle yet.
Comment 4 Javen O'Neal 2016-11-17 06:52:50 UTC
As part of our regression tests, we could also test for breakages of downstream projects, so long as they are set up with automated builds.
We test for downstream regressions with Tika, but could open this up to more downstream projects. It probably wouldn't be too difficult to find widely-used open-source projects that use POI on a project dependency search engine.

An example of this being done on pint, a python project:
Comment 5 Dominik Stadler 2016-11-18 06:08:33 UTC
I fear this won't be easy with some of the deprecations and removals that we plan to do. I would expect that any larger project quickly has at least some code-pieces that need adjustment, or?

We could prepare the necessary changes in forks, but it becomes a bit cumbersome to keep many such projects building fine...