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
