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

Reply via email to