[DISCUSS] Language detection in Solr

Hi, Solr supports pluggable language detectors : > Solr supports three implementations of this feature: > > Tika’s language detection feature: > https://tika.apache.org/1.28.4/detection.html > LangDetect language

Re: [DISCUSS] Community Virtual Meetup, March 2023

Alright, thanks everyone for the input! I've scheduled a Google Meet (meet.google.com/fso-aqtw-fdk) for March 8th at 2pm ET, and there's a Confluence page for the meeting here (https://cwiki.apache.org/confluence/display/SOLR/2023-03-08+Meeting+notes) where you can add any topics for potential dis

Re: [JENKINS] Solr-main-Linux (64bit/openj9/jdk-17.0.5) - Build # 10521 - Unstable!

This was caused by Update dependency com.tdunning:t-digest to v3.3 (#1402) (details) and I've already reverted it. Kevin Risden On Thu, Mar 2, 2023 at 10:09 AM Policeman Jenkins Server < jenk...@thetaphi.de> wrote: > Build: https://jenkins.thetaphi.de/job/Solr-main-Linux/10521/ > Java: 64bit/op

Re: Varying dependency versions? Or sacrifice Hadoop-Auth module

Maybe; same for the "sandbox" but at least externally benefits from the *possibility* of a user who wants to maintain it from doing so. That is darned close to abandonment unless such a user steps forward. But maybe that's how it has to be if we want to unblock Curator's use in Solr. The bigger

Re: Varying dependency versions? Or sacrifice Hadoop-Auth module

Would it be better to take the DIH route and let it be its own project elsewhere? With its own upgrade schedule for Solr versions? > On Mar 2, 2023, at 9:28 AM, David Smiley wrote: > > How would its location in the repo address the problem? If we release > something, we support that thing, a

Re: Varying dependency versions? Or sacrifice Hadoop-Auth module

How would its location in the repo address the problem? If we release something, we support that thing, and that means running tests. How do we run tests for a module that wants version X when Solr wants version Y? Docker and high level integration tests could be an answer but that would be a bun

Re: Google Java Style: shall we declare intent to follow?

I often find myself bike shedding names of classes and variables…. I also see contributions from folks who haven’t been in the Solr codebase for a long period of time introducing new patterns, so you end up reviewing code style more then code quality/intent. I’m a very much +1 for this.

Re: Google Java Style: shall we declare intent to follow?

Cool, thanks for the additional context. +1 to this effort. On Thu, Mar 2, 2023 at 7:18 PM David Smiley wrote: > On Thu, Mar 2, 2023 at 6:23 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > > > Can you please shed some light on what problem we'll solve by doing all > > this or wha

Re: Google Java Style: shall we declare intent to follow?

On Thu, Mar 2, 2023 at 6:23 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Can you please shed some light on what problem we'll solve by doing all > this or what motivates us to go there? > I suppose any of us could google such a generic question and find a bunch of reasonable answ

Re: Google Java Style: shall we declare intent to follow?

Can you please shed some light on what problem we'll solve by doing all this or what motivates us to go there? To my mind, Solr is a burning platform, bordering on irrelevance because of years of neglect, and all these efforts just feel like arranging deck chairs on a sinking ship. Let's do it by