FWIW I use IntelliJ and merely open the gradle project naturally. I have never run "gradlew idea" nor know what the point of that is.
On Mon, Jul 15, 2024 at 12:01 PM Ishan Chattopadhyaya <ichattopadhy...@gmail.com> wrote: > > Thanks Jason and Christos, > Apologies, I meant "./gradlew idea" instead of "./gradlew main". It > generates an IntelliJ project that didn't load for me. > I'll try to reproduce this on another machine and record a screencast for > it, to help further debugging. > Thanks and regards, > Ishan > > On Mon, 15 Jul 2024 at 17:59, Jason Gerlowski <gerlowsk...@gmail.com> wrote: > > > > Cannot resolve symbol CollectionsApi, ListCollectionsResponse. > > > > +1 to what Christos said. > > > > In short - 'CollectionsApi' and 'ListCollectionsResponse' are both > > Java classes that we generate from our OAS. That generation is setup > > in gradle to always happen prior to compiling "solr-solrj" (which of > > course happens before compiling "solr-core"). If you're not seeing > > that happen and have a short script to reproduce, I'm happy to take a > > look! > > > > > SolrCore 'collection1' is not available due to init failure: > > RAMDirectory can only be used with the 'single' lock factory type. > > > > Not sure if there's a fix yet, but David discussed this a bit recently > > in the thread "Use MockDirectoryFactory not RAMDirectoryFactory in > > test configs". > > > > As discussed there at least, it sounded like this only happens when > > using IntelliJ's "native" test-runner to run tests, instead of having > > IntelliJ utilize our gradle build. So a workaround might be to have > > IntelliJ run the tests using gradle for the time being. > > > > (And, now that I think about it, if IntelliJ isn't using the gradle > > build for some reason, it makes sense that the code-generation > > wouldn't be happening either. So maybe switching IntelliJ to using > > gradle for the test-runner might solve both of your issues?) > > > > Jason > > > > On Sun, Jul 14, 2024 at 7:40 AM Christos Malliaridis > > <c.malliari...@gmail.com> wrote: > > > > > > Hey Ishan, I'm sorry to hear that. The test uses a generated class to > > > verify the bug fix, since the issue occurs in a template fro class > > > generation. > > > > > > The error you sent points to one of generated classes that I used > > > (CollectionsApi) and that is also in SolrJ module. Since it is a > > generated > > > class, is maybe something broken with your build cache? If I am not > > > mistaken, the classes should always be generated in advance for SolrJ. > > > > > > I also tried to reproduce the error and it said for "./gradlew main" that > > > main does not exist. Is it maybe "./gradlew dev" what you are trying to > > > execute? > > > > > > > > > On Sun, 14 Jul 2024, 11:54 Ishan Chattopadhyaya, < > > ichattopadhy...@gmail.com> > > > wrote: > > > > > > > I removed the ApiMustacheTemplateTests.java temporarily, and all errors > > > > went away. > > > > However, tried running tests, and ran into this: > > > > > > > > BasicFunctionalityTest.java: > > > > java.lang.RuntimeException: > > > > org.apache.solr.core.SolrCoreInitializationException: SolrCore > > > > 'collection1' is not available due to init failure: RAMDirectory can > > only > > > > be used with the 'single' lock factory type. > > > > > > > > Any ideas, please? > > > > > > > > > > > > On Sun, 14 Jul 2024 at 14:17, Ishan Chattopadhyaya < > > > > ichattopadhy...@gmail.com> wrote: > > > > > > > > > Hi all, > > > > > I pulled latest commits, but ./gradlew main is resulting in a project > > > > that > > > > > doesn't load without errors: > > > > > ApiMustacheTemplateTests.java: Cannot resolve symbol CollectionsApi, > > > > > ListCollectionsResponse. > > > > > > > > > > Any ideas, please? > > > > > > > > > > If I rollback to the commit before the following one, it works fine: > > > > > > > > > > commit 461955f00118c69d06f50e72addeff12c8dd8169 > > > > > Author: Christos Malliaridis <c.malliari...@gmail.com> > > > > > Date: Tue Jun 11 18:15:01 2024 +0200 > > > > > > > > > > SOLR-17326: Fix references in generated SolrRequest impls (#2510) > > > > > > > > > > A handful of the v2 SolrRequest implementations generated > > > > > by our OAS spec relied on response model classes whose names > > > > > conflicted with other (unrelated) classes in solrj. This caused > > > > > errors at request time as JacksonParsingResponse would try to > > > > > deserialize the JSON, XML, etc. response body into these > > > > > unintended classes. > > > > > > > > > > This commit fixes this by modifying the 'api.mustache' template > > > > > so that generated SolrRequest classes now reference their > > > > > response model using the fully-qualified classname (i.e. > > including > > > > > the package). This resolves the ambiguity. > > > > > > > > > > --------- > > > > > > > > > > Co-authored-by: Jason Gerlowski <gerlowsk...@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
