New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core] Adopt JApiCmp to enforce control over API changes #494
Comments
There's also a sonarqube plugin, maybe that could be nice to have feedback on PRs. In any case I think this would be really useful on the Maven build. The setup doesn't appear terribly complicated, I could try that shortly. |
There is also https://revapi.org/ as an alternative. |
I've tried out now both japicmp and revapi (actually on the current master branch).
japicmp is easier to use (hence I could easily compare older versions), revapi looks more sophisticated. One incompatibility, that revapi found on master (6.30.0-SNAPSHOT <-> 6.29.0) are these two changes: pmd/pmd-core/src/main/java/net/sourceforge/pmd/lang/ast/xpath/saxon/DocumentNode.java Line 106 in 9bda5b3
pmd/pmd-core/src/main/java/net/sourceforge/pmd/lang/ast/xpath/saxon/ElementNode.java Line 98 in 9bda5b3
With #2872 we changed the return type from "Object" to "Node". This is Method Return Type Changed Covariantly which apparently is a binary incompatibility. Both classes however are annotated with @InternalApi . Is this Ok? I've configured revapi to ignore all changes, if the classes are annotated that way... Is this correct on 6.x?
Next steps:
FYI @oowekyala |
Note: There is now also https://github.com/alien-tools/breakbot, see https://github.com/breakbot-playground/pmd/pull/2/checks for a sample report |
The library (also available as a stand alone tool and a Maven plugin) checks the binary differences between 2 JARs.
This can allow us to enforce compliance with semantic versioning.
https://github.com/siom79/japicmp
The text was updated successfully, but these errors were encountered: