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 classes, we need to generate the OpenAPI spec first. But to generate the OpenAPI spec, we need to have class files for the api/model classes already produced. So to have everything in the same module, you'd need a way to tell gradle to compile some partition of its sourceSet, then run a bunch of other generation tasks, and then compile the remainder of its sourceSet. Maybe that's possible? If you can find a way to do it, I've got no objections. But to a non-expert in gradle having separate modules feels like a reasonably intuitive way to represent the relationship between these two chunks of code though 🤷. Can you elaborate at all on the benefits of avoiding the additional module? Is your concern around maintenance on the developer end? Complexity on the user end? Maybe there's something we can do to address those underlying concerns, even if we need to end up keeping the 'api' module around... -- 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
