gerlowskija opened a new pull request, #1793: URL: https://github.com/apache/solr/pull/1793
https://issues.apache.org/jira/browse/SOLR-16825 # Description SolrJ contains many SolrRequest implementations (which correspond to individual Solr APIs), but keeping them at parity and in sync with API changes made to solr-core has proved difficult and time consuming. Despite our best efforts, SolrJ lags 'core' on many APIs and lacks parity entirely on others. And that's not even considering Solr's v2 API surface, which SolrJ doesn't even attempt to cover. We can use code-generation to solve this problem. SOLR-16346 gave us the ability to generate an "OpenAPI Spec" for Solr - a comprehensive, machine-readable description of our v2 APIs. We should start leveraging this spec, using it with one of the many OpenAPI-compatible code generators out there, to produce `SolrRequest` implementations for us "for free". # Solution The solution presented in this PR integrates with the [OpenAPI Generator](https://openapi-generator.tech/) tooling to generate `SolrRequest` and `SolrResponse` pairs for each v2 API. Some notes on the implementation: 1. Our OpenAPI Spec ("OAS") has historically been produced by "solr-core", since that's where the API code itself lived. This was a problem for generating SolrJ code unfortunately: "core" depends on "solrj", so the OpenAPI spec wasn't even available until _after_ the solrj build had already finished! To address this, this PR proposes we move our OpenAPI integration to a new gradle module called 'solrj-model'. This new gradle module holds interfaces and request/response POJOs needed to represent our APIs and generate an OpenAPI spec. 2. 'solrj' depends on the new 'solrj-model' dependency and uses a new task, `openApiGenerate` to produce the generated SolrJ classes. SolrJ's `compileJava` task now "depends on" `openApiGenerate`, so this should all integrate pretty seamlessly with any IDE that loads Solr as a gradle project. 3. Currently the generated SolrJ classes use jackson-databind to serialize requests to Solr and deserialize responses. This avoids the NamedList-inspection prevalent elsewhere in SolrJ. I know we've shied away from a direct Jackson dependency in the past, but I think the idea is worth considering given the huge amount Jackson would be getting us "for free" with this approach. If there aren't strong objections, I'll plan on shading the Jackson dependency so users wouldn't have to worry about version conflicts with their own code. 4. This PR only adds a few v2 API interfaces to 'solrj-model', as a way to control scope and exhibit the approach without bloating the PR. Once the main idea has been proven, subsequent PRs can add in more APIs. 5. The generated code is _NOT_ committed to version control, as that appears to be an anti-pattern. (At least, from the poking around I did online). # Tests Existing tests continue to pass. I don't think we should add new tests for the generate code. (Openapi-generator does support this as an option, but the tests that it produces don't provide tons of value IMO.). Rather, I think we'd be better served modifying existing solr-solrj and solr-core tests to randomize between the v1 and v2 SolrRequest implementations, where both are available. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
