[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-08-04 Thread via GitHub
gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1665751760 OK, thanks for closing the loop @dsmiley. If we're OK with things as they stand, I guess I'll start cleaning this up and aim to commit sometime next week then. Once this PR lands

[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-07-31 Thread via GitHub
gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1658408834 > I think there's value in keeping SolrJ more focused on being a useful client for query & indexing that doesn't require Jackson... and having an "api" module on the side for doing all t

[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-07-27 Thread via GitHub
gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1654598386 Alright - made some decent enough progress addressing review feedback, etc. that I'm taking this out of "Draft" mode! There's still one big unanswered question that's come up so fa

[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-07-27 Thread via GitHub
gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1654436038 > My motivation is to provide an optimal experience to users -- a single JAR. I'm not sure I understand -- SolrJ has never been a single jar. It uses a bunch of Jetty libs, SLF4J,

[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-07-27 Thread via GitHub
gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1653728521 > Then could we embed "api"/model if it's inextricably a part of SolrJ? SolrJ needs to have the generated SolrRequest source code by the time 'compileJava' runs. To generate those

[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-07-26 Thread via GitHub
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** depende

[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-07-26 Thread via GitHub
gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1652129601 One thing I don't think anyone has commented on yet is the structure of the generated SolrRequest classes - do those look reasonable as-is, or is there something missing? (e.g. Factory

[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-07-26 Thread via GitHub
gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1652121987 > Might "Api" be a better name for this module? "Model" seems abstract. +1 - I waffled on the name a few times, but in hindsight I do think 'api' is better. > Putting "I" be

[GitHub] [solr] gerlowskija commented on pull request #1793: SOLR-16825: Generate v2 API SolrRequest bindings

2023-07-18 Thread via GitHub
gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1640957209 `./gradlew clean solr:solrj:openApiGenerate` generates the v2 SolrRequest and SolrResponse objects and puts them in `solr/solrj/build/generated`. That said, there's really no reaso