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