Yes, it's all in the gradle branch, locally. I would like to take it out
and put in master before moving forward with the gradle branch.
It's not a tiny amount to digest unfortunately, but the results are pretty
compelling.
I've opened an issue here: SOLR-13796: Fix Solr Test Performance
No workaround exists that I know of.
Best,
Erick
> On Sep 26, 2019, at 2:21 PM, Jyothsna Bavisetti
> wrote:
>
> Hi Shawn,
>
> Re-indexing is costly transaction in my use case as it takes more than three
> days. Please let me know if any work around?
>
> Thanks,
> Jyothsna
> -Original
But hey, we will start using the configset specified in the test on master
again!
On Thu, Sep 26, 2019 at 3:36 PM Mark Miller wrote:
> Yes, it's all in the gradle branch, locally. I would like to take it out
> and put in master before moving forward with the gradle branch.
>
> It's not a tiny
Hi all,
In https://issues.apache.org/jira/browse/SOLR-13661, we're discussing
the design of a new package management system for easy discovery,
installation and efficient upgrades of packages (containing Solr
plugins). We presented this at Activate conference this year.
I request your kind
Hi Shawn,
Re-indexing is costly transaction in my use case as it takes more than three
days. Please let me know if any work around?
Thanks,
Jyothsna
-Original Message-
From: Shawn Heisey
Sent: Thursday, September 26, 2019 11:35 PM
To: dev@lucene.apache.org
Subject: Re: Lucene index
On 9/26/2019 11:41 AM, Jyothsna Bavisetti wrote:
I am trying to upgrade Lucene index from 4.6 to 8.0.0. When I'm trying
to upgrade tool using:
java -cp lucene-core.jar:lucene-backward-codecs.jar \
org.apache.lucene.index.IndexUpgrader-delete-prior-commits \
Please let me know any option
Hi All,
I am trying to upgrade Lucene index from 4.6 to 8.0.0. When I'm trying to
upgrade tool using:
java -cp lucene-core.jar:lucene-backward-codecs.jar \
org.apache.lucene.index.IndexUpgrader -delete-prior-commits \
/scratch/***/workspaces/trunk//indexes/4.6/
Script is working fine
: In the end I fixed a bunch more bs, pulled in a bunch of improvements and
: fixes around tests from the Starburst branch that had not come over yet,
: and have generally been wrapping my magic lasso around this test suite. A
: bunch of that includes stuff in the code that was causing test
I agree. Although I also understand the concern of trying to merge the
changes while we're in the transition period... it'd be hell. I'd say
move as much stuff as possible with the current folder structure (and
ignore what cannot be ported easily) then switch as soon as possible
to gradle and hack
Of course I’ll completely defer to Dawid and Mark (well and anybody else
actually, you know, doing _work_), but just can’t resist chiming in ;).
My vote would be to “do it the Gradle way”. Yes, it’s a PITA to learn new stuff
and I won’t like it. Tough. I see no reason to carry a bunch of cruft
Thank you!
On Wed, Sep 25, 2019 at 3:26 PM Tommaso Teofili
wrote:
>
> Congrats and welcome Atri!
>
> Regards,
> Tommaso
>
> On Wed, 25 Sep 2019 at 08:55, Atri Sharma wrote:
>>
>> Thank you so much!
>>
>> On Tue, 24 Sep 2019 at 23:05, Furkan KAMACI wrote:
>>>
>>> Hi,
>>>
>>> Congrats Atri!
>>>
I pushed it in to Lucene repo (it's on Cassandra's refguide branch
anyway, so shouldn't interfere with anything else); seems like it's in
better shape than previous code anyway (those questions I asked about
the nature of the gradle port still hold though).
I got as far as building initial
12 matches
Mail list logo