> 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

Reply via email to