Re: Revisiting Standardized Test Names in Solr

Hi, I am + 1 for it too. Kind Regards, Furkan KAMACI On 3 Jun 2021 Thu at 06:55 Houston Putman wrote: > +1 > > I also am very much on the *Test side. Now that Lucene and Solr are split, > I don’t think theres much reason to base the Solr rule on Lucene’s. > > - Houston > > On Wed, Jun 2, 2021

Re: Revisiting Standardized Test Names in Solr

+1 I also am very much on the *Test side. Now that Lucene and Solr are split, I don’t think theres much reason to base the Solr rule on Lucene’s. - Houston On Wed, Jun 2, 2021 at 11:49 PM Atri Sharma wrote: > +1. > > Either way is fine, as long as its enforced. > > On Thu, 3 Jun 2021, 05:12

Re: Revisiting Standardized Test Names in Solr

+1. Either way is fine, as long as its enforced. On Thu, 3 Jun 2021, 05:12 Eric Pugh, wrote: > I’m in the *Test.java camp, but primarily care about any consistent > pattern! > > > On Jun 2, 2021, at 7:29 PM, Marcus Eagan wrote: > > Hi all, > > I am reviving this thread but perhaps it should

Re: Revisiting Standardized Test Names in Solr

I’m in the *Test.java camp, but primarily care about any consistent pattern! > On Jun 2, 2021, at 7:29 PM, Marcus Eagan > wrote: > > Hi all, > > I am reviving this thread but perhaps it should be moved to > dev@solr.apache.org given

Re: Revisiting Standardized Test Names in Solr

Hi all, I am reviving this thread but perhaps it should be moved to dev@solr.apache.org given the project-level changes. Do people favor standardizing Solr to match Lucene's convention or do you prefer *Test.java as the convention? There are many more files, and a few that don't follow either

Re: Edismax split on whitespace problems with StrField and minimum should match

Cool; I gave feedback to both. Input on SOLR-15407 in particular would be especially good from others but as it stands I don't think it should be merged. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Jun 2, 2021 at 7:50 AM Alessandro

Re: Solr/Lucene joint development workflow?

Thanks for digging into this! I can confirm that my lucene-*-9.0.0-SNAPSHOT.jar files have META-INF/services/ with all the expected codecs. I did remove the lucene subfolder from the maven repo, re-ran `gradlew mavenToLocalRepo`, manually verified that the expected META-INF/services/ listed all

RE: Solr/Lucene joint development workflow?

FYI, I did a recompile locally and checked the JAR files in my local Maven repository ("./gradlew mavenToLocalRepo"): All contain META-INF/services with all Codecs. I have no idea what goes wrong on your side. Next I will try to setup mavenLocal() and a SNAPSHOT dependency, too. - Uwe

Edismax split on whitespace problems with StrField and minimum should match

I have isolated two problems with edismax, split on whitespace and minimum should match: https://github.com/apache/solr/pull/129 https://github.com/apache/solr/pull/158 So far David Smiley and Jan Høydahl gave an initial feedback, they are small fixes but quite important in my opinion as they

RE: Solr/Lucene joint development workflow?

I'd suggest to remove the whole Lucene subfolder from your local Maven repo. E.g., rm -rf ~/.m2/repository/org/apache/lucene Then compile and deploy Lucene again. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message-

RE: Solr/Lucene joint development workflow?

Hi, this error helps. It looks like the lucene-core.jar file does not have the META-INF/services. I wonder how Solr works! It would be good to figure out what's going on and why the JAR files in your local repository do not have the required META-INF/services subfolder. Uwe - Uwe

Re-introducing ant precommit on branch_8x

Hi When we did the split, we "wiped" the master branch of lucene-solr repo. But we also wiped the .github folder containing the useful ant precommit github action for branch_8x. Please see https://github.com/apache/lucene-solr/pull/2503 where I propose to re-introduce that action so backport