gerlowskija commented on PR #1793:
URL: https://github.com/apache/solr/pull/1793#issuecomment-1652388788
> [Houston] SolrJ core also doesn't need to depend on this solrj-model or
solrj-api module, so that doesn't need to be opt-in or opt-out
😬 As things are today, SolrJ **is** dependent on the 'api' module. The
generated SolrRequest files use POJO classes that live in 'api' to represent
request and response bodies.
As an example, here's the ctor of the generated SolrRequest class called
'AddReplicaProperty'. The `AddReplicaPropertyRequestBody` class is defined in
the 'api' module.
```
public AddReplicaProperty(
String collName, String shardName, String replicaName, String
propName) {
super(
SolrRequest.METHOD.valueOf("PUT"),
"/collections/{collName}/shards/{shardName}/replicas/{replicaName}/properties/{propName}"
.replace("{" + "collName" + "}", collName)
.replace("{" + "shardName" + "}", shardName)
.replace("{" + "replicaName" + "}", replicaName)
.replace("{" + "propName" + "}", propName));
...<snip>...
this.requestBody = new AddReplicaPropertyRequestBody();
}
```
----
We don't have to do this if we don't want to. We can drop the solrj->api
dependency if we really want - we'd just need to tweak our openapi-generator
invocation to also generate "model" classes that are near duplicates of the
POJOs that already live in the 'api' submodule. I actually had that working
earlier on in this POC but dropped it because at the time I didn't see a reason
to generate classes that were such close duplicates of Java code we already
had. If you guys think generating models makes sense though, I'm OK with
reversing course.
Would we really need to make the 'api' module "opt-in" for 9.x? I'm sure
I'm showing my naiveté here, but client libraries change their deps all the
time in non-major releases, don't they? What benefit does "opt-in" get our
users?
--
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]
