nick-boss-tech opened a new pull request, #5283: URL: https://github.com/apache/solr/pull/5283
🤖 *AI text below* 🤖 *(reviewed by Nick Shanin)* Draft status is due to Nick Shanin's open-PR cap; the change is complete and ready for review. Jira: https://issues.apache.org/jira/browse/SOLR-18617 (split out of SOLR-18600 at [~ab]'s suggestion on that ticket) **What happens today** Nothing in the build notices when a public SolrJ type or member disappears between releases. SOLR-18600 is the worked example: SolrJ 10.1.0 removed `HttpSolrClientBase` and `HttpSolrClientBuilderBase`, which 10.0.0 had shipped, and the break surfaced only when a downstream consumer failed at runtime. A release-time or post-release comparison catches that after the fact; a build check catches it in the change that causes it. **What this change does** `:solr:solrj:check` now compares the built SolrJ jars against the previous release and fails on unexcused binary-incompatible changes. * [`gradle/validation/binary-compat.gradle`](https://github.com/apache/solr/blob/8a31263736f1967f128198153e138f785ee4a03c/gradle/validation/binary-compat.gradle) adds `binaryCompatReport` and `checkBinaryCompat` to `:solr:solrj` and wires the check into its `check` task. The comparison uses japicmp in-process and covers the built solrj jar plus the solr-api jar, against the same pair from the baseline release, at protected-and-above access. * The baseline is the `solrj.binaryCompat.baselineVersion` property (default 10.1.0 on this line) and resolves through a detached configuration, so the property selects exactly the release compared; a named configuration would fall under dependency locking and stay pinned to the locked release. `solrj.binaryCompat.enabled=false` turns the check off, for example on a major line where breaks are allowed. * [`solr/solrj/binary-compat-exclusions.txt`](https://github.com/apache/solr/blob/8a31263736f1967f128198153e138f785ee4a03c/solr/solrj/binary-compat-exclusions.txt) is the review surface for accepted breaks: one entry per change, with the ticket and reason required. An entry that matches no current change draws a warning, so stale entries surface instead of rotting. **Proof** Verification at `8a31263736f1967f128198153e138f785ee4a03c`: * `:solr:solrj:check -x test` passes. The report found 1 binary-incompatible change against the 10.1.0 baseline, excused by the single exclusions entry (SOLR-18450): "Binary compatibility check passed against SolrJ 10.1.0 (1 excused change(s), 1 exclusion(s))." * Discrimination: the same check pointed at 10.0.0 (`-Psolrj.binaryCompat.baselineVersion=10.0.0`) fails, as it should. The report counts 481 binary-incompatible changes against 10.0.0 and the failure list includes `org.apache.solr.client.solrj.impl.HttpSolrClientBase: CLASS_REMOVED` and `org.apache.solr.client.solrj.impl.HttpSolrClientBuilderBase: CLASS_REMOVED`, the SOLR-18600 break. * `:solr:solrj:tidy` passes with no file changes. **Limits** The check covers SolrJ only (the solrj and solr-api jars); other modules have no equivalent guard here. It reports binary-incompatible changes at protected-and-above access, so source-incompatible but binary-compatible changes, and package-private or private changes, are out of scope by design. Whether the removed classes from SOLR-18600 are restored stays on that ticket; this PR is only the check. *Nick Shanin directed the work and takes responsibility for this contribution.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
