Re: [jira] [Commented] (SOLR-13390) Provide Query Elevation Component by default

[Eric Pugh]

Isn’t the point of introducing Plugins to Solr to reduce what is on by default? 
  And deal with potentially issues like this?

> On Feb 19, 2020, at 2:50 PM, Chris M. Hostetter (Jira)  
> wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/SOLR-13390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040379#comment-17040379
>  ] 
> 
> Chris M. Hostetter commented on SOLR-13390:
> ---
> 
> the main issue would be ensuring we don't break backcompat for people who 
> already have QEC configured -- even if they have it configured with a weird 
> name. (ie: it's not enough to say "don't register a QEC if a component with 
> the name 'elevate' already exists")
> 
> the second thing to consider is what kind of implicit configuration this new 
> implicit QEC instance should have? ... should it's "configured elevations" be 
> hardcoded with an "empty set" or should it be configured to look for a file 
> with a specific name (like "elevate.xml") that is happily ignores if it 
> doesn't exist but happily loads if it does? 
> 
>> Provide Query Elevation Component by default
>> 
>> 
>>Key: SOLR-13390
>>URL: https://issues.apache.org/jira/browse/SOLR-13390
>>Project: Solr
>> Issue Type: Bug
>>   Reporter: Erik Hatcher
>>   Priority: Major
>> 
>> Like other components, like highlighting and faceting, it'd be useful to 
>> have this work out of the box by just enabling it on the request.   
>> Currently the component needs to be added to `/select` and an empty 
>> elevate.xml file needs to be added to the config - a bit unnecessarily 
>> arduous.
>> Let's add the component to `/select` and modify the component to be happy 
>> with or without an elevate.xml (since id's can be sent on the request to 
>> elevate, so fixed config isn't needed either).
> 
> 
> 
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
> 
> -
> To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
> For additional commands, e-mail: issues-h...@lucene.apache.org
> 

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: [jira] [Commented] (SOLR-599) Lightweight SolrJ client

[Jan Høydahl]

It would be cleanest to avoid compile time deps in solrj-core and have a 
separate ZkCloudSolrClient in solr-zk.

But perhaps easier sort term to just slice it up in the packaging stage when 
creating pom, and accept ClassNotFound unless you also add solrj-zk to path... 
I’m not enough into the solrj module to know how easy it is to carve out parts 
of it..

Jan Høydahl

> 19. feb. 2020 kl. 20:21 skrev Gus Heck (Jira) :
> 
> 
>[ 
> https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040356#comment-17040356
>  ] 
> 
> Gus Heck commented on SOLR-599:
> ---
> 
> Do those HTTP API's have a way to proactively advise the client of changes to 
> aliases, available nodes etc? or do they require/conduct polling? Isn't one 
> of the primary reasons we have zk because it allows the client to watch for 
> changes? I've been meaning to look into this but keep getting distracted by 
> other things so I better just mention it :). I remember having some 
> difficulty with the http providers when the tests randomly selected them 
> while I was working on TRAs, but they may have improved since then.
> 
>> Lightweight SolrJ client
>> 
>> 
>>Key: SOLR-599
>>URL: https://issues.apache.org/jira/browse/SOLR-599
>>Project: Solr
>> Issue Type: Improvement
>> Components: clients - java, SolrJ
>>   Reporter: Shalin Shekhar Mangar
>>   Priority: Minor
>>Fix For: 4.9, 6.0
>> 
>>Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, 
>> SOLR-599.patch
>> 
>> 
>> SolrJ provides a SolrServer implementation backed by commons-httpclient 
>> which introduces many dependency jars (commons-codec, commons-io and 
>> commons-logging). Apart from that SolrJ also uses StAX API for XML parsing 
>> which introduces dependencies like stax-api, stax and stax-utils.
>> This enhancement will add a SolrServer implementation backed by 
>> java.net.HttpUrlConnection and will use BinaryResponseParser as the default 
>> response parser. Using this basic implementation out of the box would 
>> require no dependencies on either commons-httpclient or StAX. The only 
>> dependency would be on solr-commons making this a very lightweight and 
>> distribution friendly Java client for Solr.
> 
> 
> 
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
> 
> -
> To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
> For additional commands, e-mail: issues-h...@lucene.apache.org
> 

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

Re: SolrJ has 29 compile-time dependencies!

[Jan Høydahl]

I added a comment to https://issues.apache.org/jira/browse/SOLR-599 
"Lightweight SolrJ client" From June 2008 (!) 
Let’s continue discussion there?

Jan

> 19. feb. 2020 kl. 16:19 skrev David Smiley :
> 
> I definitely care about this issue. I like the idea of splitting off a 
> solr-zk module. Few people know that CloudSolrClient can do a pure HTTP mode 
> to get cluster state indirectly from ZK via Solr, thus no necessity of 
> talking with ZK and what that entails architecturally (security concerns). 
> 
> Whenever someone proposes changes to SolrJ impacting dependencies, we need to 
> be super clear about that; needs it’s own issue or dev list message 
> announcement. Code reviews will help. I can’t stand dependency creep in SolrJ!
> 
> (FYI I have almost no internet connectivity this week. )
> 
> On Mon, Feb 17, 2020 at 7:26 PM Jan Høydahl  > wrote:
> The netty deps are there solely because they are needed by zookeeper client 
> when talking to zookeeper over the new https transport with netty.
> So a quick win would be to make a solrj-zk.jar which depends on 
> zookeeper-client.jar along with netty and its other dependencies, and thus 
> keep solrj-core clean of these.
> 
> It would be great to be able to choose what HTTP lib to use in SolrJ. 
> Obviously you want Jetty-HTTP2-client to do fancy things such as 
> bring-your-own-client with interceptors and what not, but for the simple case 
> we should be just fine with Java11 client in solrj-core.
> 
> Looking at the solrj module there are 756 Java classes in there. So we use 
> SolrJ as some common module and perhaps it is a bit too easy to just throw 
> new stuff in there,, not really considering this is all going to end up in 
> every user’s classpath + dependencies?
> 
> Jan
> 
>> 17. feb. 2020 kl. 23:24 skrev Robert Muir > >:
>> 
>> Yes why would this library have any dependencies at all? In trunk java 11 is 
>> a minimum, and JDK11+ has HTTP client capable of HTTP/2, https, etc. So 
>> seeing both netty and jetty client libraries makes no sense at all.
>> 
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/package-summary.html
>>  
>> 
>> 
>> 
>> On Mon, Feb 17, 2020 at 6:44 AM Jan Høydahl > > wrote:
>> Hi
>> 
>> According to 
>> https://mvnrepository.com/artifact/org.apache.solr/solr-solrj/8.4.1 
>>  SolrJ 
>> now has 29 compile-time dependencies. Those are the ones explicitly 
>> mentioned in ivy.xml and I believe that the number would be even higher if 
>> we used transitive dependencies.
>> That means that if you want to include SolrJ in a small app for just 
>> searching Solr, you get a ton of dependencies in your project that you may 
>> not need and that increase the chance of collision with other libs in your 
>> all.
>> 
>> So I want to raise the question whether it is time to take some action here.
>> 
>> Otions may include:
>> Get rid of unneeded deps
>> Explicitly exclude deps from gradle build that we know we do not need
>> Modularize SolrJ into a solrj-core and solrj-xxx, where solrj-core would be 
>> the minimum anyone would need to do the basics
>> Look into shading select libs that often cause collisions
>> 
>> Let the discussion begin :)
>> 
>> Jan
> 
> -- 
> Sent from Gmail Mobile

Re: SolrJ has 29 compile-time dependencies!

[David Smiley]

I definitely care about this issue. I like the idea of splitting off a
solr-zk module. Few people know that CloudSolrClient can do a pure HTTP
mode to get cluster state indirectly from ZK via Solr, thus no necessity of
talking with ZK and what that entails architecturally (security concerns).

Whenever someone proposes changes to SolrJ impacting dependencies, we need
to be super clear about that; needs it’s own issue or dev list message
announcement. Code reviews will help. I can’t stand dependency creep in
SolrJ!

(FYI I have almost no internet connectivity this week. )

On Mon, Feb 17, 2020 at 7:26 PM Jan Høydahl  wrote:

> The netty deps are there solely because they are needed by zookeeper
> client when talking to zookeeper over the new https transport with netty.
> So a quick win would be to make a solrj-zk.jar which depends on
> zookeeper-client.jar along with netty and its other dependencies, and thus
> keep solrj-core clean of these.
>
> It would be great to be able to choose what HTTP lib to use in SolrJ.
> Obviously you want Jetty-HTTP2-client to do fancy things such as
> bring-your-own-client with interceptors and what not, but for the simple
> case we should be just fine with Java11 client in solrj-core.
>
> Looking at the solrj module there are 756 Java classes in there. So we use
> SolrJ as some common module and perhaps it is a bit too easy to just throw
> new stuff in there,, not really considering this is all going to end up in
> every user’s classpath + dependencies?
>
> Jan
>
> 17. feb. 2020 kl. 23:24 skrev Robert Muir :
>
> Yes why would this library have any dependencies at all? In trunk java 11
> is a minimum, and JDK11+ has HTTP client capable of HTTP/2, https, etc. So
> seeing both netty and jetty client libraries makes no sense at all.
>
>
> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/package-summary.html
>
>
> On Mon, Feb 17, 2020 at 6:44 AM Jan Høydahl  wrote:
>
>> Hi
>>
>> According to
>> https://mvnrepository.com/artifact/org.apache.solr/solr-solrj/8.4.1
>> SolrJ now has 29 compile-time dependencies. Those are the ones explicitly
>> mentioned in ivy.xml and I believe that the number would be even higher if
>> we used transitive dependencies.
>> That means that if you want to include SolrJ in a small app for just
>> searching Solr, you get a ton of dependencies in your project that you may
>> not need and that increase the chance of collision with other libs in your
>> all.
>>
>> So I want to raise the question whether it is time to take some action
>> here.
>>
>> Otions may include:
>>
>>- Get rid of unneeded deps
>>- Explicitly exclude deps from gradle build that we know we do not
>>need
>>- Modularize SolrJ into a solrj-core and solrj-xxx, where solrj-core
>>would be the minimum anyone would need to do the basics
>>- Look into shading select libs that often cause collisions
>>
>>
>> Let the discussion begin :)
>>
>> Jan
>>
>
> --
Sent from Gmail Mobile

Re: JDK 14 is now in the Release Candidate Phase

[Rory O'Donnell]

Hi Uwe,

Any issues to report on your testing of the release candidate ?

Rgds,Rory

On 10/02/2020 14:52, Uwe Schindler wrote:


Hi Rory,

Policeman Jenkins is now testing the release candidate build of JDK-14 
and JDK-15-ea+9.


Uwe

-

Uwe Schindler

uschind...@apache.org

ASF Member, Apache Lucene PMC / Committer

Bremen, Germany

https://lucene.apache.org/

*From:* Rory O'Donnell 
*Sent:* Monday, February 10, 2020 12:33 PM
*To:* Uwe Schindler 
*Cc:* rory.odonn...@oracle.com; Dalibor Topic 
; Balchandra Vaidya 
; Deepak Nenmelithara Damodaran 
; Dawid Weiss 
; dev@lucene.apache.org

*Subject:* JDK 14 is now in the Release Candidate Phase

Hi Uwe & Dawid,

*Per the JDK 14 schedule [1]  , we are now in the Release Candidate 
Phase *


The stabilization repository, jdk/jdk14, *is open for P1 bug fixes 
*per the JDK Release Process (JEP 3) [2].

All changes require approval via the Fix-Request Process [3].
For more details, see Mark Reinhold's email to jdk-dev mailing list [4]

OpenJDK 14 EA build 36 is now available at http://jdk.java.net/14

  * These early access, open source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
.

OpenJDK 15 EA build 9 is now available at http://jdk.java.net/15

  * These early access, open source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
.
  * Significant changes since the last availability email:

  o build 8

  + JDK-8235783: DatagramSocket::disconnect should allow an
implementation to throw UncheckedIOException
  + JDK-8237528: Inefficient compilation of Pattern Matching
for instanceof

  # Reported by JaCoCo.

  o build 7

  + JDK-8236105: DatagramSocket.send() and
MulticastSocket.send() methods throw an
IllegalArgumentException
  + JDK-8231422: Better serial filter handling
  + JDK-8227758: More valid PKIX processing
  + JDK-8230318: Better trust store usage
  + JDK-8234484: Add ability to configure third port for
remote JMX

Project Loom Early-Access Builds - Build 15-loom+3-20 (2020/1/27)

  * These early-access builds are provided under the GNU General
Public License, version 2, with the Classpath Exception
.
  * These builds are intended for developers looking to "kick the
tyres" and provide feedback on using the API or by sending bug
reports. Warning: This build is based on an incomplete version of
JDK 14 .

Links to FOSDEM Videos that might be of interest:

  * https://twitter.com/OpenJDK/status/1225008387009785857
  * https://twitter.com/OpenJDK/status/1225011154159833088
  * https://twitter.com/OpenJDK/status/1225009792596488193

Regards,
Rory

[1] https://openjdk.java.net/projects/jdk/14/#Schedule
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003885.html 



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


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

Re: 8.5 release

[Ignacio Vera]

+1

On Tue, Feb 18, 2020 at 7:26 PM Jan Høydahl  wrote:

> +1
>
> That should give us time to update release docs for the new website too.
>
> Jan Høydahl
>
> 18. feb. 2020 kl. 18:28 skrev Adrien Grand :
>
> 
> +1
>
> On Tue, Feb 18, 2020 at 4:58 PM Alan Woodward 
> wrote:
>
>> Hi all,
>>
>> It’s been a while since we released lucene-solr 8.4, and we’ve
>> accumulated quite a few nice new features since then.  I’d like to
>> volunteer to be a release manager for an 8.5 release.  If there's
>> agreement, then I plan to cut the release branch two weeks today, on
>> Tuesday 3rd March.
>>
>> - Alan
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Adrien
>
>

Re: Link doesn't validate

[Dawid Weiss]

Thanks Jan!

On Wed, Feb 19, 2020 at 11:10 AM Jan Høydahl  wrote:
>
> I fixed that as part of my latest commit for some other parts of the ref 
> guide.
>
> Jan
>
> > 19. feb. 2020 kl. 09:38 skrev Dawid Weiss :
> >
> > Erick - your latest commit to the solr guide doesn't pass gradlew
> > check (and fails with ant as well):
> >
> > https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/25767/consoleText
> >
> > I don't know how to fix - seems like the link format requires an
> > explicit anchor (?).
> >
> > D.
> >
> > -
> > 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
>

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

Re: Link doesn't validate

[Jan Høydahl]

I fixed that as part of my latest commit for some other parts of the ref guide.

Jan

> 19. feb. 2020 kl. 09:38 skrev Dawid Weiss :
> 
> Erick - your latest commit to the solr guide doesn't pass gradlew
> check (and fails with ant as well):
> 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/25767/consoleText
> 
> I don't know how to fix - seems like the link format requires an
> explicit anchor (?).
> 
> D.
> 
> -
> 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

Link doesn't validate

[Dawid Weiss]

Erick - your latest commit to the solr guide doesn't pass gradlew
check (and fails with ant as well):

https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/25767/consoleText

I don't know how to fix - seems like the link format requires an
explicit anchor (?).

D.

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