> 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 <[email protected]> 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, <[email protected]> > 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 < > > [email protected]> 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 <[email protected]> > > > 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 <[email protected]> > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
