If I do "gw compile" twice without doing anything, we should expect a fully up-to-date gradle build. Instead, openApiGenerate outputs a bunch of stuff (perhaps it's our most noisy task?) including that it cleaned the output and did generation. My expectation is that it should do nothing and ideally print nothing either.
On Thu, Jun 6, 2024 at 9:16 AM David Smiley <dsmi...@apache.org> wrote: > > 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
