gerlowskija commented on PR #1866: URL: https://github.com/apache/solr/pull/1866#issuecomment-1701747937
Kindof? That approach works fine as far as JAX-RS and Solr are concerned. In fact I'm sure you noticed it's how things were structured when these classes lived in 'core'. The problem is code-generation. As each SolrRequest class is being generated, it needs to be able to import the Java POJOs it relies on. Right now our template has some pretty simple logic around imports - we essentially expect all POJOs to be in a single package without any static class nesting that'd change the import pattern. (see [here](https://github.com/apache/solr/blob/3cbb97549cef1664a1d6b01fd2d1367cefbb0665/solr/solrj/build.gradle#L135) and [here](https://github.com/apache/solr/blob/3cbb97549cef1664a1d6b01fd2d1367cefbb0665/solr/solrj/src/resources/java-template/api.mustache#L39)) (openapi-generator has the ability to generate model POJOs for users, and handles imports much more gracefully in this case. We've decided _not_ to generate models though, since they'd essentially duplicate the POJOs that we already have. The "import" problem is the main downside of that decision.) Anyway, this feels like a fixable problem to me if it's worth it to us to dig in. I spent a few hours tweaking the OpenAPI spec and `api.mustache` template without much success, but there's gotta be some fix out there. I guess it just depends how strongly we care about being able to have POJOs nested the way @HoustonPutman described... -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
