SOLR-16825: 'api' module migration, pt 5 #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Vincent Primault <[email protected]>
ConfigSetService.checkConfigExists() should not require solrconfig.xml to exist; the parent directory's existence is fine. Users may choose for their config to be a different name, after all.
-- suggests CloudSolrStream concurency race condition
…d the kernel version
…on poolsize (closes apache#1842)
…re using watchers (apache#1945)
Co-authored-by: Christine Poerschke <[email protected]>
…Values=True only) (apache#1950)
….22.0 (apache#1701) * Update dependency com.google.errorprone:error_prone_annotations to v2.22.0 Co-authored-by: Kevin Risden <[email protected]>
Co-authored-by: Jan Høydahl <[email protected]> Co-authored-by: Kevin Risden <[email protected]>
This commit covers the create APIs for collections, shards and replicas. It also covers the collection and core level "install-shard-data" APIs. Extracting annotated interfaces for these APIs includes them in the SolrRequest- generation we now do in SolrJ
Co-authored-by: Kevin Risden <[email protected]>
Wide variety of fixes to the docs related to indexing to account for evolution of Solr 9x and Lucene 9x --------- Co-authored-by: Andrey Bozhko <[email protected]> Co-authored-by: Eric Pugh <[email protected]>
…apache#1743) Co-authored-by: Kevin Risden <[email protected]>
…under randomized context SOLR-16960 (apache#1983)
…ESTAPPLYUPDATES (apache#1965) RESTORECORE now sets the UpdateLog to ACTIVE state instead of requiring a separate REQUESTAPPLYUPDATES call in Collection restore. The latter will still happen in 9.x for backwards-compatibility. --------- Co-authored-by: Julia Maimone <[email protected]> Co-authored-by: David Smiley <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://issues.apache.org/jira/browse/SOLR-16825
Description
SOLR-16825 added a new gradle module, 'api', which holds v2 API definitions as interfaces. This allows us to generate an OAS (and SolrRequest implementations from that) as a part of the solrj build.
But these artifacts (the OAS and generated Java code), only cover the v2 APIs that have interfaces in the 'api' module. We need to extract interfaces to live in 'api' for each v2 API in 'core' that doesn't already have one.
Solution
This PR creates 'api' interfaces for a number of v2 APIs, allowing SolrRequest implementations to be generated for them. The following APIs are covered in this PR:
Tests
PR is a refactor, so doesn't add any additional tests. But manual testing has been done to make sure the affected v2 APIs continue to work, and existing tests continue to pass.
Checklist
Please review the following and check all that apply:
mainbranch../gradlew check.