@ijuma at this point it is only a report that can be run manually, it's not part of the build task. The reason for this is that the compare tool (japicmp) requires two sets compiled jars (old and new) and it is quite lengthy to compile both: it takes about 3-4 minutes and I think it should be enough if only Jenkins bounces the commit back. Improvement idea 1. should reduce it to the half of this time. Let me know if you think we should add this to the local build as well. There is the `failOnSemanticIncompatibility` option that I added which fails the task if there binary incompatible changes on a minor/maintenance release branch. Just propagated the corresponding cli option from here: http://siom79.github.io/japicmp/CliTool.html. Alternatively the `failOnBinaryIncompatibility` option could be used too on minor and maintenance branches to achieve the same effect. For now I specified 3 packages as API to check: `org.apache.clients.*`, `org.apache.common.*` and `org.apache.connect.*`. I'm hoping you can give me more input on how to refine this list, I can easily imagine that this list is by far not complete (for instance shall we include streams too?).
Adding it to the Jenkins jobs however can absolutely be done with some extra steps. For instance in case of trunk: since the previous release was 2.0.0 we need to specify that to the Jenkins build as well (unfortunately "specifying the previous release" can't be automated, we need to figure it out manually for each job). I've created a test Jenkins job on which I've done something like this: ``` # do the build/test before this report # # branches must be local for now, we need to check them out git checkout $BASE_BRANCH #2.0.0 git checkout $BRANCH #trunk (2.1.0.dev) # this is to check out the PR git fetch origin pull/5620/head:api-compatibility-report git checkout api-compatibility-report # # This can be specified in an "Invoke Gradle Script" build step but copied the command line launch here ./gradlew apiCompatibilityReport -PbaseBranch=$BASE_BRANCH -PnewBranch=$BRANCH -PfailOnSemanticIncompatibility=true ``` So if you're on the 2.1.x development branch, you need to set 2.0 as the base branch I didn't want to add it to the standard build because generating this report usually takes 3-4 minutes as it practically checks out the two branch to compare and jars them. Some possible ways to improve this: 1. Use the currently built artifacts if they are available. For instance in the case above we wouldn't need to compile trunk once again as during the build process all the required jars were built. This would spare 1-2 minutes for the build. 2. Checking dependencies: binary incompatible dependencies might be an issue in case of minor and maintenance releases. For instance we upgrade the Jackson dependency to one which is binary incompatible with the previous one could break a Kafka user when they want to upgrade by swapping out the client jar. [ Full content available at: https://github.com/apache/kafka/pull/5620 ] This message was relayed via gitbox.apache.org for [email protected]
