Lucene Highlighting Not Working Properly!!
Hello Team , I am using a lucene highlighter which is not properly working Can you please help me to sort this issue. Thanks & Regards, Ajay.
Re: StreamExpressionTest failures
This just started failing out of the blue today. I wonder what changed? Is
it straightforward to detect windows in the test cases?
Joel Bernstein
http://joelsolr.blogspot.com/
On Thu, Jun 25, 2020 at 7:46 PM Erick Erickson
wrote:
> This test fails on line 3500, here’s the code block. Notice that the test
> carefully constructs
> the test string with the system file separator. Even so, the the tuple has
> a *nix style separator
> and the test string a Windows separator.
>
>
> final String expectedSecondLevel1Path = "directory1" + File.separator +
> "secondLevel1.txt";
> for (int i = 0; i < 4; i++) {
> Tuple t = tuples.get(i);
> assertEquals("secondLevel1.txt line " + String.valueOf(i+1),
> t.get("line"));
> assertEquals(expectedSecondLevel1Path, t.get("file"));
> }
>
> FAILED:
> org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testCatStreamDirectoryCrawl
>
> Error Message:
> expected: but
> was:
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
StreamExpressionTest failures
This test fails on line 3500, here’s the code block. Notice that the test
carefully constructs
the test string with the system file separator. Even so, the the tuple has a
*nix style separator
and the test string a Windows separator.
final String expectedSecondLevel1Path = "directory1" + File.separator +
"secondLevel1.txt";
for (int i = 0; i < 4; i++) {
Tuple t = tuples.get(i);
assertEquals("secondLevel1.txt line " + String.valueOf(i+1), t.get("line"));
assertEquals(expectedSecondLevel1Path, t.get("file"));
}
FAILED:
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testCatStreamDirectoryCrawl
Error Message:
expected: but was:
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
Thanks Erick! Mike McCandless http://blog.mikemccandless.com On Tue, Jun 23, 2020 at 5:18 PM Erick Erickson wrote: > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if > there are any warnings in the code. See LUCENE-9411. I’ve finally finished > suppressing over 8,000 warnings in Solr, so could check this in. Many > thanks to Dawid for helping me with the Gradle parts. The goal now is to > not add any _more_ SuppressWarnings if at all possible. I hope we can start > taking the suppressions out when we’re working on code, so when working on > code please consider removing some of them. > > I was hoping that we could also fail ant builds, but there are some tricky > dependencies in third party code that weren’t easy to resolve in the ant > world due to licensing issues, if you’re interested in details, see the > JIRA or ping me on Slack. One consequence of this is that 8x will NOT fail > on warnings, neither will Ant builds on 9x. If someone wants to try working > that out, please feel free but I’m just really tired of banging my head > against that wall. > > So please, Please, PLEASE start compiling 9x with Gradle or cover your > ears to keep from hearing me complain. And I’ve been taking lessons from my > 3 1/2 year old grandson on doing that LOUDLY. > > About SuppressWarnings. There were so many of them that there was no hope > of actually fixing the underlying causes in one go. I’ve enhanced the > BadApples report to start reporting on the number of SuppressWarnings in > each file week to week when they increase or decrease. I’ll be nudging > people if the number of SuppressWarnings starts going up, starting Monday. > I can’t help but think understanding generics will be improved by working > through new warnings. > > A couple of side notes for IntelliJ users (IDK about other IDEs, but I’d > be surprised if there weren’t similar capabilities): > > - When you just open the project, Gradle is automatically configured. > There’s no need to execute the “gradlew idea” task. > > - You can execute tasks in IntelliJ _really easily_ by clicking on them in > the gradle window, it’s on the extreme right. It seems much more robust > than trying the same thing in Ant. > > -- The “assemble” task will bring up a convenient window showing errors > (including warnings) that you can click on and get right to the offending > code. “classes” and “testClasses” are also very useful tasks to execute in > this context. > > - The “inspections” in IntelliJ point out a lot of things, but not > anything with SuppressWarnings. It may be worth coming to consensus on > which inspections are worth enabling. And perhaps distributing a > configuration. For instance, do we really care for inspections reporting > “blah could be final”? They’re highlighted in yellow in my setup, and I’ve > done nothing special. Spend some time looking at those when you’re working > on code… the number of “method may return null” inspections is scary. Have > we’ve ever had the released code generate an NPE or anything like that > . > > - Please do NOT suppress the _inspections_ in IntelliJ. One of the choices > IntelliJ offers is to suppress an inspection, and it adds a > “suppressInspection” comment to the source code specific to IntelliJ. This > is different than Javas’s SuppressWarnings, and we shouldn’t include > comments in the code specific to a particular IDE. > > - The motivation here is that we need all the help from the compiler we > can get when it comes to as large and complex a code base as Lucene/Solr. > Yes, it feels constraining. Yes, it means we won’t feel as productive > because we have to take time to address things we’ve been ignoring. The > leap of faith is that if we spend a bit of time up front, we can avoid > having to spend a lot _more_ time fixing errors later in the release cycle. > The time it takes to fix a problem goes up exponentially the farther down > the cycle it’s caught. Fixing something when developing may take T minutes. > Some time later when test start failing, it takes T*X. And when you > consider community-wide implications of releasing code, getting feedback > from the field, filing a JIRA, trying to reproduce the problem, checking > the code, and pushing a fix, the cost of fixing something after it’s > released goes up enormously. I’m not saying that addressing all the > complaints something like IntelliJ’s inspections show will magically make > it unnecessary to make point releases, but avoiding just a few is a win. > > > Erick > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Review your squash-merge message to remove duplicate text
Ilan, your checkout is not up to date then. Here they are on GitHub: https://github.com/apache/lucene-solr/commit/57a892f896f543913d6b22a81577f69184cd94b6 https://github.com/apache/lucene-solr/commit/25428013fb0ed8f8fdbebdef3f1d65dea77129c2 https://github.com/apache/lucene-solr/commit/26075fc1dc06766a9d2af8bd5dd14243c0463a6b That means that for most squash and merge the dialog box should be left > empty, as the PR title should already have the relevant info (Jira ID + > short description), right? And when the PR title does not contain this > info, we should edit it prior to commit. > *If* you manage to have a nice 1-liner title that you think is sufficient, then it's fine. Perhaps it's something simple/obvious. But most commits I do and see of others have more helpful details. As a reader of other people's commits, I *really* appreciate that. Even if I could go to the JIRA issue for other details, it's helpful to see them in the commit message. ~ David On Thu, Jun 25, 2020 at 1:36 AM Ilan Ginzburg wrote: > I could only git show the last id in your email David. > > That means that for most squash and merge the dialog box should be left > empty, as the PR title should already have the relevant info (Jira ID + > short description), right? And when the PR title does not contain this > info, we should edit it prior to commit. > Making sure I understand you correctly. > > Ilan > > On Thu, Jun 25, 2020 at 6:00 AM David Smiley wrote: > >> Fellow committers, >> >> When hitting that squash-merge button in GitHub UI, the first line of the >> dialog for the commit message is set apart from the rest of the message. >> Then it's followed by a multi-line text box for the remaining lines. The >> beginning line of the rest of the message is often duplicated or >> effectively redundant with that first title line. Please edit your message >> so that the redundancy is gone because the whole thing winds up in the >> commit message, which is ultimately rather untidy/unclean. >> >> Most commits are fine. Here are some examples of the problem I speak of >> by 3 separate individuals: >> >> 57a892f896f543913d6b22a81577f69184cd94b6 >> 25428013fb0ed8f8fdbebdef3f1d65dea77129c2 >> 26075fc1dc06766a9d2af8bd5dd14243c0463a6b >> >> Thanks, >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
> The Gradle precommit task was put there for “back compat”. Since > “check” depends on “precommit”, check may contain, now or in future, more > than precommit. IDK whether they’re identical at this point, Dawid put in > that magic. > Hmmm we might want to add a note that “gradlew check” does both. I think I > might > add that in the help text for gradle though.. "check" is gradle convention and many existing plugins will automatically attach validation tasks to it (so it's better to get used to it rather that fight against it). Also: "check" can be run per-project while "precommit" is typically a global (top-level) task. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
