I can dedicate a bit to it if someone makes a Jira so i completely understand the issue.
- Houston On Tue, Aug 13, 2024 at 8:29 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > Hi David, > > Maybe this deserves its own thread? > > I also see the behavior you described - the openApiGenerate task > appears to regenerate on each build. Perhaps this is "expected" when > using the task's "cleanOutput=true" setting? Or maybe the task just > doesn't track "inputs" the way Gradle tasks typically do, to know when > it needs to run? Or I guess it's also possible that the Gradle task > in general would behave as desired, but that we've set it up > incorrectly somehow? > > In any case, definitely worth a JIRA ticket or a dedicated thread to > discuss. > > Best, > > Jason > > On Tue, Aug 13, 2024 at 12:38 PM David Smiley <dsmi...@apache.org> wrote: > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
