Re: SOLR-13412 (Make the Lucene Luke module available from a Solr distribution)

[Tomoko Uchida]

Hi Erick,

> 2> Currently, invoking it is an ant task, it’s not build/distributed. How
this will work out in the Gradle build is TBD.

As for this point, I think we should consider SOLR-13412 and LUCENE-9442
separately, since the former is about making a distribution package and the
latter is about providing a helper for developers.

Tomoko


2020年8月7日(金) 22:28 Erick Erickson :

> All:
>
> I’m not sure this really makes sense at this point. I’ve outlined the
> current state on the JIRA. The sort form is:
>
> 1> there’s some work currently being done to make the stand-alone Luke app
> work in the Gradle world.
>
> 2> Currently, invoking it is an ant task, it’s not build/distributed. How
> this will work out in the Gradle build is TBD.
>
> 3> I’m not sure trying to make this easily accessible from Solr ("bin/solr
> luke" or similar) even in the event that the Gradle build creates the
> entire standalone app adds enough value to make it worth the effort. We
> have a subset of functionality with the Luke Request Handler, and people
> who need the deeper dive that Luke provides can download the source and
> execute the Gradle task.
>
> So I’m thinking of closing the JIRA as “won’t fix”.
>
> Please add comments to the JIRA
>
> Erick
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Missing class for tests

[Noble Paul]

I believe that's lost for good . We probably will have decompile and  add it

On Sat, Aug 8, 2020 at 7:42 AM Gus Heck  wrote:
>
> This test looks like an excellent Idea by the way. It's going to catch many 
> things that break back compat on plugins which is great, but we need a way to 
> regenerate the binary files it's loading. Such regeneration should probably 
> be a build target, and a comment in the test class regarding how to do that 
> (and pointing out the significance of doing so)
>
> -Gus
>
> On Fri, Aug 7, 2020 at 5:25 PM Gus Heck  wrote:
>>
>> Does anyone have (and can check in) the code for this class? I've got a 
>> failure loading this class but I can't troubleshoot it because apparently 
>> only a binary file is checked in...
>>
>> NS2-MacBook-Pro:lucene-solr gus$ grep -r "MyTextField" *
>> solr/core/src/test/org/apache/solr/pkg/TestPackages.java:  "
>> 'class':'schemapkg:my.pkg.MyTextField',\n" +
>> Binary file solr/core/src/test-files/runtimecode/schema-plugins.jar.bin 
>> matches
>>
>> -Gus
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)



-- 
-
Noble Paul

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Standardize Leading Test or Trailing Test

[Jason Gerlowski]

+1

On Fri, Aug 7, 2020 at 8:37 PM Marcus Eagan  wrote:
>
> Any -1's? I just learned more about them from David Smiley earlier today and 
> I recognize they are for the rare case, but I want to ensure consensus before 
> I spend time on this tomorrow evening. I hadn't remembered seeing them in 
> real life except for on the Lucene/Solr separation vote.
>
> Of course, if someone else does this before I get to it today or tomorrow 
> morning, great. :)
>
> Marcus
>
> On Thu, Aug 6, 2020 at 8:05 AM Gus Heck  wrote:
>>
>> Yeah  +1 for standardization +1.01 if it lands on *Test :) but that's just 
>> my personal preference.
>>
>> On Thu, Aug 6, 2020 at 9:17 AM Adrien Grand  wrote:
>>>
>>> +1
>>>
>>> On Thu, Aug 6, 2020 at 1:54 PM Erick Erickson  
>>> wrote:

 This has amused/annoyed me for a long time. But did I ever have the 
 energy to tackle it? N.

 +1

 > On Aug 6, 2020, at 1:50 AM, Tomás Fernández Löbbe 
 >  wrote:
 >
 > +1
 >
 > On Wed, Aug 5, 2020 at 10:37 PM David Smiley  
 > wrote:
 > +1 to standardize on something.
 > This has been brought up before: LUCENE-8626 -- credit to Christine who 
 > started the work.  I recommend resuming the discussion there.
 >
 > ~ David
 >
 >
 > On Thu, Aug 6, 2020 at 12:08 AM Anshum Gupta  
 > wrote:
 > +1
 >
 > Thanks for bringing this up, Marcus. Standardizing this is really great.
 >
 > On Wed, Aug 5, 2020 at 8:01 PM Marcus Eagan  
 > wrote:
 > Hi community, what do you think a small effort to standardize on leading 
 > with the word "Test" or trailing with the word "Test" in the repo. Most 
 > projects do one or the other and it has an impact on developer 
 > productivity. I'll explain my use case:
 >
 > I'm working on a class and I want to modify the test to evaluate my 
 > changes. If the class is named in a standard way, I can find it easily. 
 > If it is not, it's fine. There are typically two options. I consider it 
 > distracting and sloppy. Distraction is expensive for developers. I have 
 > some more important efforts that I'm working on, but if the community 
 > agrees on this one, I can open a ticket and submit a PR. Let me know 
 > what you think.
 >
 > Hoping to make the project more developer friendly.
 >
 > --
 > Marcus Eagan
 >
 >
 >
 > --
 > Anshum Gupta


 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

>>>
>>>
>>> --
>>> Adrien
>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
>
> --
> Marcus Eagan
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Standardize Leading Test or Trailing Test

[Marcus Eagan]

Any -1's? I just learned more about them from David Smiley earlier today
and I recognize they are for the rare case, but I want to ensure consensus
before I spend time on this tomorrow evening. I hadn't remembered seeing
them in real life except for on the Lucene/Solr separation vote.

Of course, if someone else does this before I get to it today or tomorrow
morning, great. :)

Marcus

On Thu, Aug 6, 2020 at 8:05 AM Gus Heck  wrote:

> Yeah  +1 for standardization +1.01 if it lands on *Test :) but that's just
> my personal preference.
>
> On Thu, Aug 6, 2020 at 9:17 AM Adrien Grand  wrote:
>
>> +1
>>
>> On Thu, Aug 6, 2020 at 1:54 PM Erick Erickson 
>> wrote:
>>
>>> This has amused/annoyed me for a long time. But did I ever have the
>>> energy to tackle it? N.
>>>
>>> +1
>>>
>>> > On Aug 6, 2020, at 1:50 AM, Tomás Fernández Löbbe <
>>> tomasflo...@gmail.com> wrote:
>>> >
>>> > +1
>>> >
>>> > On Wed, Aug 5, 2020 at 10:37 PM David Smiley 
>>> wrote:
>>> > +1 to standardize on something.
>>> > This has been brought up before: LUCENE-8626 -- credit to Christine
>>> who started the work.  I recommend resuming the discussion there.
>>> >
>>> > ~ David
>>> >
>>> >
>>> > On Thu, Aug 6, 2020 at 12:08 AM Anshum Gupta 
>>> wrote:
>>> > +1
>>> >
>>> > Thanks for bringing this up, Marcus. Standardizing this is really
>>> great.
>>> >
>>> > On Wed, Aug 5, 2020 at 8:01 PM Marcus Eagan 
>>> wrote:
>>> > Hi community, what do you think a small effort to standardize on
>>> leading with the word "Test" or trailing with the word "Test" in the repo.
>>> Most projects do one or the other and it has an impact on developer
>>> productivity. I'll explain my use case:
>>> >
>>> > I'm working on a class and I want to modify the test to evaluate my
>>> changes. If the class is named in a standard way, I can find it easily. If
>>> it is not, it's fine. There are typically two options. I consider it
>>> distracting and sloppy. Distraction is expensive for developers. I have
>>> some more important efforts that I'm working on, but if the community
>>> agrees on this one, I can open a ticket and submit a PR. Let me know what
>>> you think.
>>> >
>>> > Hoping to make the project more developer friendly.
>>> >
>>> > --
>>> > Marcus Eagan
>>> >
>>> >
>>> >
>>> > --
>>> > Anshum Gupta
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> --
>> Adrien
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>


-- 
Marcus Eagan

Re: Missing class for tests

[Gus Heck]

This test looks like an excellent Idea by the way. It's going to catch many
things that break back compat on plugins which is great, but we need a way
to regenerate the binary files it's loading. Such regeneration should
probably be a build target, and a comment in the test class regarding how
to do that (and pointing out the significance of doing so)

-Gus

On Fri, Aug 7, 2020 at 5:25 PM Gus Heck  wrote:

> Does anyone have (and can check in) the code for this class? I've got a
> failure loading this class but I can't troubleshoot it because apparently
> only a binary file is checked in...
>
> NS2-MacBook-Pro:lucene-solr gus$ grep -r "MyTextField" *
> solr/core/src/test/org/apache/solr/pkg/TestPackages.java:  "
>  'class':'schemapkg:my.pkg.MyTextField',\n" +
> Binary file solr/core/src/test-files/runtimecode/schema-plugins.jar.bin
> matches
>
> -Gus
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>


-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Missing class for tests

[Gus Heck]

Does anyone have (and can check in) the code for this class? I've got a
failure loading this class but I can't troubleshoot it because apparently
only a binary file is checked in...

NS2-MacBook-Pro:lucene-solr gus$ grep -r "MyTextField" *
solr/core/src/test/org/apache/solr/pkg/TestPackages.java:  "
 'class':'schemapkg:my.pkg.MyTextField',\n" +
Binary file solr/core/src/test-files/runtimecode/schema-plugins.jar.bin
matches

-Gus

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: SolrClient and making requests asynchronously

[David Smiley]

Maybe the method could be overloaded with an executor... there's a balance
between expert control and simplicity.  Shrug.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Thu, Aug 6, 2020 at 10:56 AM Bram Van Dam  wrote:

> > public CompletableFuture>
> requestAsync(SolrRequest request);
>
> NamedList aside, this looks like a great async API to me. But I
> would still like some control over the thread pool/executor that's being
> used.
>
> Maybe that doesn't have to be part of the requestAysnc method signature,
> maybe it could be part of the SolrClient constructor/builder, but then
> maybe I'll want a different one for reads and writes? So maybe an
> overloaded version of requestAsync with an extra paramater for a thread
> pool/executor?
>
>  - Bram
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

RE: ASF Jenkins moved to new URL

[Uwe Schindler]

Hi,

thanks for the hint! I missed to migrate those 2 jobs to new server. They
are migrated now and show up in the directory.

But I have no idea if they are ever called at the moment. The parent
precommit job by ASF that triggers this is not there, so nobody with call
those thingies. So I think we have to wait until this is setup by ASF. This
affects issue, not pull requests, right? As PR are handled by Github, IMHO.

I will keep an exe on that, the jobs are there.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Chris Hostetter 
> Sent: Friday, August 7, 2020 8:17 PM
> To: Uwe Schindler 
> Cc: dev@lucene.apache.org
> Subject: Re: ASF Jenkins moved to new URL
> 
> 
> Thanks for the ping Uwe, reports tool udated iwth new url...
> 
> https://github.com/hossman/jenkins-
> reports/commit/68d42574fb4b306254653f7f72ae7ff01d6c3992
> 
> ...it seemed to work locally, public reports should start showing correct
> data in a few hours.
> 
> (Although i don't see any 'PreCommit' jobs yet showing up in the build
> log? ... my reports are designed to ignore those since thery are expected
> to have failures, but i'm not sure if the "ignore" rule will work w/o
> seeing what their new job names/urls look like)
> 
> 
> 
> : Date: Thu, 6 Aug 2020 18:08:55 +0200
> : From: Uwe Schindler 
> : To: Chris Hostetter 
> : Cc: dev@lucene.apache.org
> : Subject: ASF Jenkins moved to new URL
> :
> : Hi Hossman,
> :
> : as you are doing the statistics on Jenkins, I just wanted to give you a
> : ping, because the build servers of ASF changed to Cloudbees. It's still
> : jenkins, but different structure.
> :
> : I moved all jobs over yesterday, there are still some issue (a reboot is
> : required to enable a plugin needed for "Nightly" jobs and a permissions
> : problem for refguide must be fixed. Nevertheless, the API should be
> : compatible, but there are no veiws anymore. The jobs can be found here:
> : https://ci-builds.apache.org/job/Lucene/
> :
> : It's a "folder" and no "view" anymore (only at ASF, policeman is still
> : different). I think your script should be able to handle that, but would
be
> : good to check. The new structure also have its own slave nodes (lucene1
and
> : lucene2 is private to jobs from the lucene folder). The old jenkins is
still
> : visible, but all jobs are disabled there - as no node is there anymore
to
> : execute them. It will be switched off on Aug 15th.
> :
> : Uwe
> :
> : -
> : Uwe Schindler
> : Achterdiek 19, D-28357 Bremen
> : https://www.thetaphi.de
> : eMail: u...@thetaphi.de
> :
> :
> :
> 
> -Hoss
> http://www.lucidworks.com/


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: ASF Jenkins moved to new URL

[Chris Hostetter]

Thanks for the ping Uwe, reports tool udated iwth new url...

https://github.com/hossman/jenkins-reports/commit/68d42574fb4b306254653f7f72ae7ff01d6c3992

...it seemed to work locally, public reports should start showing correct 
data in a few hours.

(Although i don't see any 'PreCommit' jobs yet showing up in the build 
log? ... my reports are designed to ignore those since thery are expected 
to have failures, but i'm not sure if the "ignore" rule will work w/o 
seeing what their new job names/urls look like)



: Date: Thu, 6 Aug 2020 18:08:55 +0200
: From: Uwe Schindler 
: To: Chris Hostetter 
: Cc: dev@lucene.apache.org
: Subject: ASF Jenkins moved to new URL
: 
: Hi Hossman,
: 
: as you are doing the statistics on Jenkins, I just wanted to give you a
: ping, because the build servers of ASF changed to Cloudbees. It's still
: jenkins, but different structure.
: 
: I moved all jobs over yesterday, there are still some issue (a reboot is
: required to enable a plugin needed for "Nightly" jobs and a permissions
: problem for refguide must be fixed. Nevertheless, the API should be
: compatible, but there are no veiws anymore. The jobs can be found here:
: https://ci-builds.apache.org/job/Lucene/
: 
: It's a "folder" and no "view" anymore (only at ASF, policeman is still
: different). I think your script should be able to handle that, but would be
: good to check. The new structure also have its own slave nodes (lucene1 and
: lucene2 is private to jobs from the lucene folder). The old jenkins is still
: visible, but all jobs are disabled there - as no node is there anymore to
: execute them. It will be switched off on Aug 15th.
: 
: Uwe
: 
: -
: Uwe Schindler
: Achterdiek 19, D-28357 Bremen
: https://www.thetaphi.de
: eMail: u...@thetaphi.de
: 
: 
: 

-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Migrating to Cloudbees

[Ishan Chattopadhyaya]

Thanks for your work, Uwe. I would love to run a public Jenkins server soon
(maybe be September), would like to try out your scripts :-)

On Fri, Aug 7, 2020 at 10:12 PM David Smiley  wrote:

> Sweet!  Thanks Uwe!
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Aug 6, 2020 at 5:52 PM Uwe Schindler  wrote:
>
>> Thanks Erick!
>>
>> I hope the remaining issues sort out quite soon.
>>
>> For the release managers: As I did a more scripted, automatic migration
>> using the Jenkins REST API (otherwise the 50 jobs we have would have been a
>> desaster to migrate), I already have a plan to reuse that script to allow
>> the release manager to create clones of all "master" jobs, preconfigured
>> for the release branch. All you need is a Lucene PMC status and a Jenkins
>> API Token and then you will be able to start a script who creates all
>> release branch jobs in a few seconds 
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Erick Erickson 
>> > Sent: Thursday, August 6, 2020 11:39 PM
>> > To: dev@lucene.apache.org
>> > Subject: Migrating to Cloudbees
>> >
>> > If nobody has expressed their _extreme_ gratitude to Uwe, infra (and
>> helpers?)
>> > for the migration, I hereby rectify that!!
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Migrating to Cloudbees

[David Smiley]

Sweet!  Thanks Uwe!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Thu, Aug 6, 2020 at 5:52 PM Uwe Schindler  wrote:

> Thanks Erick!
>
> I hope the remaining issues sort out quite soon.
>
> For the release managers: As I did a more scripted, automatic migration
> using the Jenkins REST API (otherwise the 50 jobs we have would have been a
> desaster to migrate), I already have a plan to reuse that script to allow
> the release manager to create clones of all "master" jobs, preconfigured
> for the release branch. All you need is a Lucene PMC status and a Jenkins
> API Token and then you will be able to start a script who creates all
> release branch jobs in a few seconds 
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Erick Erickson 
> > Sent: Thursday, August 6, 2020 11:39 PM
> > To: dev@lucene.apache.org
> > Subject: Migrating to Cloudbees
> >
> > If nobody has expressed their _extreme_ gratitude to Uwe, infra (and
> helpers?)
> > for the migration, I hereby rectify that!!
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Naming of non-SolrCloud clusters in the Ref Guide

[Cassandra Targett]

The suggestion to use “managed” and maybe “self-managed” is an interesting one. 
Do you think it’s possible some might confuse that with the other ways we use 
managed - like the “managed-schema”, and “managed resources” (synonyms and stop 
words)? Neither of those are cluster-specific, and I wonder if the overlap in 
terminology would cause them to be conflated.

Cassandra
On Aug 6, 2020, 10:51 AM -0500, Ilan Ginzburg , wrote:
> Both "legacy" and "SolrCloud" clusters are search server clusters. Seen from 
> far enough, they look the same.
>
> In "legacy" the management code is elsewhere (developed by the client 
> operating the cluster, running on other machines using a diferent logic and 
> potentially another DB than Zookeeper) whereas in "SolrCloud" the management 
> code is embedded in the search server(s) code and it happens that (currently) 
> this code relies on Zookeeper.
>
> I see SolrCloud as a "managed cluster" vs. legacy that would be "Self 
> managed" by the client, or "U manage" (non managed when looking at it from 
> the Solr codebase perspective).
>
> Same idea as coordinated vs uncoordinated basically. I don't know why but I 
> prefer "managed".
>
> Ilan
>
> > On Thu, Aug 6, 2020 at 5:49 PM Cassandra Targett  
> > wrote:
> > > On Aug 6, 2020, 10:22 AM -0500, Gus Heck , wrote:
> > > > WRT the name "uncoordinated mode" I fear it could be read (or even 
> > > > become known as) as "clumsy mode" which is humorous but possibly not 
> > > > what we're going for :)
> > >
> > > I had also considered “non-coordinated”, and prefer it but couldn’t 
> > > articulate why. The association of “uncoordinated" with clumsiness might 
> > > be what was bugging me.
> > > >  I'd perhaps suggest Cluster mode for SolrCloud though I'm not entirely 
> > > > sure if Legacy Solr (in curren parlance) is not a "cluster" too, 
> > > > cluster being a somewhat vague term. However Clustered Mode and Legacy 
> > > > Mode seem more on target. I think "Legacy" could be changed since we're 
> > > > not really planning on abandoning it (are we?), but
> > >
> > > One can have a cluster and not run SolrCloud. I think from an operations 
> > > perspective, several servers all running Solr is considered a cluster, no 
> > > matter what tools are being used to get them to talk to each other.
> > >
> > > I think “Legacy” (also used today already in some contexts) is 
> > > problematic because there aren’t plans to abandon it. Also “Legacy 
> > > replication” is pretty close to exactly what PULL replicas use to poll 
> > > leaders and pull new index segments when needed. IOW, it’s not “legacy”, 
> > > it’s very actively being used in a growing number of clusters. That might 
> > > be an implementation detail users aren’t aware of, but I feel the term is 
> > > really lacking mostly in that it just doesn’t say anything besides “it’s 
> > > older”.
> > > > the adjective there SHOULD communicate reduced functionality because 
> > > > there are plenty of features that are cloud (cluster) only.
> > >
> > > In my view, the reduced functionality of non-SolrCloud clusters is mostly 
> > > around coordination of requests, leader election, configs, and other 
> > > similar automated activities one does manually otherwise. So, I feel that 
> > > sort of proves my point - a word that conveys lack of coordination is a 
> > > good option for what it’s called. If there is a better antonym for 
> > > “coordinated”, I’m all for considering it but haven’t yet been able to 
> > > think of/find one.
> > >
> > > I think it’s important to think about what differentiates the two ways of 
> > > managing a Solr cluster and derive the naming from that. What features of 
> > > SolrCloud don’t exist in the non-SolrCloud approach? What words help us 
> > > generalize those gaps and can any of them be an appropriate name?
> > > >
> > > > -Gus
> > > >
> > > > On Thu, Aug 6, 2020 at 10:27 AM Cassandra Targett 
> > > >  wrote:
> > > > > The work in SOLR-14702 has left us with some awkward phrasing (which 
> > > > > is still better than what it was) around non-SolrCloud clusters that 
> > > > > I've offered to help fix.
> > > > >
> > > > > I think we've struggled for years to find a good name for 
> > > > > non-SolrCloud clusters and we've used a number of variations: "legacy 
> > > > > replication" (which it isn't, since PULL replicas use the same 
> > > > > thing), "Standalone mode" (which it isn't because it's a cluster), 
> > > > > now "leader/follower mode" (which could be confusing because 
> > > > > SolrCloud has leaders).
> > > > >
> > > > > Yesterday I thought about what really differentiates a SolrCloud 
> > > > > cluster and a non-SolrCloud cluster and it occurred to me that a key 
> > > > > difference is the former is coordinated by ZooKeeper, while the 
> > > > > latter is not. That led me to think that perhaps "coordinated mode" 
> > > > > can someday be a better replacement for the term "SolrCloud", while 
> > > > > "uncoordinated mode" could be a 

SOLR-13412 (Make the Lucene Luke module available from a Solr distribution)

[Erick Erickson]

All:

I’m not sure this really makes sense at this point. I’ve outlined the current 
state on the JIRA. The sort form is:

1> there’s some work currently being done to make the stand-alone Luke app work 
in the Gradle world.

2> Currently, invoking it is an ant task, it’s not build/distributed. How this 
will work out in the Gradle build is TBD.

3> I’m not sure trying to make this easily accessible from Solr ("bin/solr 
luke" or similar) even in the event that the Gradle build creates the entire 
standalone app adds enough value to make it worth the effort. We have a subset 
of functionality with the Luke Request Handler, and people who need the deeper 
dive that Luke provides can download the source and execute the Gradle task.

So I’m thinking of closing the JIRA as “won’t fix”.

Please add comments to the JIRA

Erick
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

JDK 15 is now in the Initial Release Candidate Phase

[Rory O'Donnell]

Hi Uwe & Dawid,

*Per the JDK 15 schedule  , we are now in the Initial Release Candidate 
Phase

*


***Please advise if you have any open high priority issues.***

 * Schedule for JDK 15
 o *2020/08/06 Initial Release Candidate*
 o 2020/08/20 Final Release Candidate
 o 2020/09/15 General Availability

**

 * The overall feature set is frozen.
 o Per the JDK Release Process [1] we now turn our focus to P1 bugs.
 * Features included in JDK 15:
 o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
   
 o JEP 360: Sealed Classes (Preview) 
 o JEP 371: Hidden Classes 
 o JEP 372: Remove the Nashorn JavaScript Engine
   
 o JEP 373: Reimplement the Legacy DatagramSocket API
   
 o JEP 374: Disable and Deprecate Biased Locking
   
 o JEP 375: Pattern Matching for instanceof (Second Preview)
   
 o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
   
 o JEP 378: Text Blocks 
 o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
   
 o JEP 381: Remove the Solaris and SPARC Ports
   
 o JEP 383: Foreign-Memory Access API (Second Incubator)
   
 o JEP 384: Records (Second Preview)
   
 o JEP 385: Deprecate RMI Activation for Removal
   

*JDK 15 **Early Access build 35 *is now available at http://jdk.java.net/15

 * Release notes
 o http://jdk.java.net/15/release-notes
 * Recent fixes that might be of interest
 o Build 34
 + JDK-8246094: [macos] Sound Recording and playback is not working

*JDK 16 Early Access build 9 ***is now available at http://jdk.java.net/16

 * JEP Candidate
 o JEP 388: Windows/AArch64 Port 
 * JEPs targeted to JDK 16, so far:
 o JEP 369: Migrate to GitHub 
 o JEP 357: Migrate from Mercurial to Git
   
 o JEP 347: Enable C++14 Language Features
   

**

 * Recent fixes that might be of interest
 o

   Build 9

 + JDK-8243320: Add SSL root certificates to Oracle Root CA program
 + JDK-8243321: Add Entrust root CA - G4 to Oracle Root CA program
 o Build 8
 + JDK-8246094: [macos] Sound Recording and playback is not working
 + JDK-8248655: Support supplementary characters in String case
   insensitive operations
 o Build 7
 + JDK-8246032: Implementation of JEP 347: Enable C++14
   Language Features


*__*
Rgds,Rory


[1] http://openjdk.java.net/jeps/3

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland