It's not split packages afaik: both sets of SolrRequest classes end up
in the same solrj jar
On Tue, Jan 14, 2025 at 5:26 PM Gus Heck wrote:
>
> >
> > It makes sense for all our
> > SolrRequest/SolrResponse implementations to be in the same package,
> >
> regardless of their provenance.
> >
>
> T
On Tue, Jan 14, 2025 at 12:48 PM David Smiley wrote:
> Any way, for V1, CloudSolrClient sends a parameter like this:
>_stateVer_=collection1:3
> It's used for distributed ClusterState cache invalidation by
> CloudSolrClient.[1]. It's a list of collections and their versions
> (consider that a
+1 (binding)
SUCCESS! [0:37:10.192767]
I also ran the solr operator integration tests with it:
Ran 27 of 28 Specs in 509.267 seconds
> SUCCESS! -- 27 Passed | 0 Failed | 0 Pending | 1 Skipped
It was very hard to get the docker image to build, because GPG behaves a
little differently now.
But
>
> It makes sense for all our
> SolrRequest/SolrResponse implementations to be in the same package,
>
regardless of their provenance.
>
That sentiment sounds like "split packages" which is a practice that runs
contrary to the way the java module system works with respect to jars,
though I'm not s
Please vote for release candidate 1 for *Solr 9.8.0*
*The artifacts can be downloaded from:*
https://dist.apache.org/repos/dist/dev/solr/solr-9.8.0-RC1-rev-8bf0100e502ade4b8161e4b90f762b117a6ef442
If you're running on MacOS, due to an update to the integration tests, you
would need to install co
Jason said:
> There's not currently a "shard-level" path for querying, but other
> APIs currently exist at the
> "/collections/someColl/shards/someShardName" path, so it's only a
> small leap to offering querying there.
>
So Jersey/OpenAPI will have no problem with all the core handlers being
add
Hello everyone,
I would like to merge https://github.com/apache/solr/pull/2925 next week,
after doing some small cleanups.
The PR improves the way our dependencies are resolved by introducing a
platform module that automatically adds all our dependencies from our
version catalog (gradle/libs.vers
I'm not a big fan of matrix parameters to identify the resource we want to
target.
To me, as a guideline, the path of the URL is to target a resource, which
in the Solr case is a collection/shard/core and a handler. Then parameters,
or the query part of the URL, give other details like the action
