It worked! There's a PR here with the fix: https://github.com/apache/solr/pull/2502. Take a look when you get a chance and let me know what you think!
(I haven't created a JIRA ticket, since it's a minor change to our build. If anyone would prefer a JIRA ticket to document this beyond what this dev-thread and Github PR provide, let me know.) Best, Jason On Thu, Jun 6, 2024 at 7:05 AM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > > Yeah, this is definitely a pain from time to time. > > For anyone who hasn't hit this, steps to reproduce are: > > 1. Start on a branch that has a new JAX-RS-annotated interface in > Solr's 'api' module. > 2. Any gradle task that compiles SolrJ will build Solr's OpenAPI spec, > generate SolrRequest implementations from that spec, and add them to > solrj's build directory as a part of its "source set". These > generated classes often reference 'model' classes (e.g. request or > response POJOs) that exist on the current branch, but may not be on > other branches. > 3. Switch to a new branch, which lacks the new JAX-RS API. > 4. If solrj is compiled without running "clean" first, the previously > generated SolrRequest implementations will fail to compile (because > the request/response POJOs they rely on are missing). > > In terms of *when* this happens, I often see it when changing from a > PR-branch to main. Though you can also see it going from 'main' to > 'branch_9x', if 'main' has a JAX-RS API that hasn't been backported > yet. > > I've been a little despairing in the past about fixing this- I know it > should be done, but my gradle knowledge is pretty lacking. Though I > notice in writing this email that the 'openApiGenerate' task itself > has a few options that might fix this without any broader gradle > changes, particularly the "cleanupOutput" and "skipOverwrite" options. > I'll try playing with those a bit and report back if there's any > promise. > > Best, > > Jason > > > On Tue, Jun 4, 2024 at 6:52 PM David Smiley <dsmi...@apache.org> wrote: > > > > I noticed some generated source files, and in particular > > solr/solrj/build/generated/src/main/java/org/apache/solr/client/solrj/request/FileStoreApi.java > > that suddenly had a compilation issue. This is almost certainly due > > to the API evolving, and SOLR-17302 in particular. Just do "gradlew > > clean" to start fresh. I've hit this a couple times for different > > specific API issues over some months. > > > > Still... should the build be smart enough to avoid this? For example > > if the generator is blind to the output directory's contents, we may > > as well clean the generated directory fully first. On the other hand, > > maybe it smartly recognizes existing generated stuff and can tell that > > it doesn't need to re-generate (like javac). > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
