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 > >
