SOLR-17161 Create the solrj-jetty module

[janhoy]

Separates out new solr-solrj module and moves the jetty specific classes from solrj.

Needed to generalize ConcurrentUpdateBaseSolrClient, and Claude Code chose to do that by abstracting out a new StreamingResponse class.

I did NOT implement a ConcurrentUpdateJdkSolrClient in this PR, although it should be possible based on the new generic base class...

https://issues.apache.org/jira/browse/SOLR-17161

[janhoy]

This is the dependency:tree for org.apache.solr:solr-solrj before this change:

org.example:testsolrj:jar:1.0-SNAPSHOT
\- org.apache.solr:solr-solrj:jar:11.0.0-SNAPSHOT:compile
   +- org.apache.solr:solr-api:jar:11.0.0-SNAPSHOT:compile
   |  +- io.swagger.core.v3:swagger-annotations-jakarta:jar:2.2.22:compile
   |  +- jakarta.ws.rs:jakarta.ws.rs-api:jar:3.1.0:runtime
   |  \- org.semver4j:semver4j:jar:6.0.0:runtime
   |     \- org.jspecify:jspecify:jar:1.0.0:runtime
   +- org.eclipse.jetty.http2:jetty-http2-client:jar:12.0.27:compile
   |  +- org.eclipse.jetty:jetty-alpn-client:jar:12.0.27:compile
   |  \- org.eclipse.jetty.http2:jetty-http2-common:jar:12.0.27:compile
   |     \- org.eclipse.jetty.http2:jetty-http2-hpack:jar:12.0.27:compile
   +- com.fasterxml.jackson.core:jackson-databind:jar:2.20.1:runtime
   +- com.fasterxml.jackson.core:jackson-annotations:jar:2.20:compile
   +- com.fasterxml.jackson.core:jackson-core:jar:2.20.1:runtime
   +- org.slf4j:slf4j-api:jar:2.0.17:compile
   +- org.eclipse.jetty.http2:jetty-http2-client-transport:jar:12.0.27:runtime
   +- org.eclipse.jetty:jetty-http:jar:12.0.27:compile
   +- org.eclipse.jetty:jetty-client:jar:12.0.27:runtime
   +- org.eclipse.jetty:jetty-util:jar:12.0.27:compile
   +- org.eclipse.jetty:jetty-io:jar:12.0.27:compile
   +- org.slf4j:jcl-over-slf4j:jar:2.0.17:runtime
   \- org.eclipse.jetty:jetty-alpn-java-client:jar:12.0.27:runtime

And this is after

org.example:testsolrj:jar:1.0-SNAPSHOT
\- org.apache.solr:solr-solrj:jar:11.0.0-SNAPSHOT:compile
   +- org.apache.solr:solr-api:jar:11.0.0-SNAPSHOT:compile
   |  +- io.swagger.core.v3:swagger-annotations-jakarta:jar:2.2.22:compile
   |  +- jakarta.ws.rs:jakarta.ws.rs-api:jar:3.1.0:runtime
   |  \- org.semver4j:semver4j:jar:6.0.0:runtime
   |     \- org.jspecify:jspecify:jar:1.0.0:runtime
   +- com.fasterxml.jackson.core:jackson-databind:jar:2.20.1:runtime
   +- com.fasterxml.jackson.core:jackson-annotations:jar:2.20:compile
   +- com.fasterxml.jackson.core:jackson-core:jar:2.20.1:runtime
   +- org.slf4j:slf4j-api:jar:2.0.17:runtime
   \- org.slf4j:jcl-over-slf4j:jar:2.0.17:runtime

[janhoy]

I dont like Object as type, can we imagine a more specific type that is generic enough for the purpose?

[janhoy]

@dsmiley Object is simple, I guess a modern alternative is to use generics:

public class ConcurrentUpdateJettySolrClient extends ConcurrentUpdateBaseSolrClient<org.eclipse.jetty.client.Response> 

and

public interface StreamingResponse<R>

Touches all the same 5 files and all signatures, avoids Object but the API perhaps gets more complicated to understand..

[Copilot]

Pull request overview

This PR introduces a new solrj-jetty module to separate Jetty-specific HTTP client code from the core solrj module. This allows users to opt out of Jetty dependencies if they choose to use alternative HTTP client implementations.

Key Changes

• Created new StreamingResponse abstraction interface to decouple ConcurrentUpdateBaseSolrClient from Jetty-specific types
• Moved Jetty-dependent classes from solrj to new solrj-jetty module
• Updated ConcurrentUpdateBaseSolrClient.onSuccess() signature to accept generic Object instead of Jetty Response

Reviewed changes

Copilot reviewed 34 out of 49 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
solr/solrj/src/java/org/apache/solr/client/solrj/impl/StreamingResponse.java	New abstraction interface for HTTP streaming responses
solr/solrj/src/java/org/apache/solr/client/solrj/impl/ConcurrentUpdateBaseSolrClient.java	Refactored to use StreamingResponse abstraction
solr/solrj/build.gradle	Removed Jetty dependencies, added test artifact configuration
solr/solrj-jetty/build.gradle	New module build configuration with Jetty dependencies
solr/solrj-jetty/src/java/org/apache/solr/client/solrj/jetty/*	Jetty-specific client implementations moved from solrj
solr/test-framework/build.gradle	Added dependency on solrj-jetty module
settings.gradle	Added solrj-jetty module to project
changelog/unreleased/SOLR-17161-separate-jetty-solrj.yml	Changelog entry for the change

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dsmiley]

Thanks for getting this across the line! If I had known 10.0 RC would be in 2026, I'd have done it.

Just some minor feedback. The use of "Object" where you commented is fine.

[dsmiley]

Did you actually have to add all of these to make the build happy?
Use of them is each a work-around to a deficiency in the cutterslade plugin . Sometimes I wonder if we'd be better off without that thing. Maybe sharing this pittiful situation here with that project may motivate a proper fix there.

[janhoy]

Yea, without these, we get:

FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':solr:solrj-jetty:analyzeTestClassesDependencies'.
> Dependency analysis found issues.
  unusedDeclaredArtifacts
   - commons-io:commons-io:2.20.0@jar
   - org.apache.httpcomponents:httpclient:4.5.14@jar
   - org.apache.httpcomponents:httpcore:4.4.16@jar
   - org.apache.lucene:lucene-core:10.3.2@jar
   - org.apache.zookeeper:zookeeper-jute:3.9.4@jar
   - org.eclipse.jetty.ee10:jetty-ee10-webapp:12.0.27@jar
   - org.eclipse.jetty:jetty-server:12.0.27@jar
   - org.eclipse.jetty:jetty-session:12.0.27@jar
   - org.mockito:mockito-core:5.19.0@jar

Not sure if there is a better solution? @malliaridis ?