Thanks Jason! On Thu, Jun 6, 2024 at 9:02 AM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > > 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 >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
