[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929225#comment-16929225 ] Uwe Schindler commented on LUCENE-8951: --- OK, all jobs changed by them with "Configuration Slicer" -> "Editable e-mail-notification". > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929222#comment-16929222 ] Uwe Schindler commented on LUCENE-8951: --- I am on INFRA Slack if we can use the configuartion slicing plugin for the change on ASF jenkins, its way to many jobs to do it one by one. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929118#comment-16929118 ] Uwe Schindler commented on LUCENE-8951: --- Not sure how we handle the "announce list" only. We had to remove the "moderate subscribers" flag, as this also affects the "allow" list. I think the problem is solved by the Reply-To setting, but it's now possible that subscribers can send mail to the list (if they use mail address explicitely). > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929116#comment-16929116 ] Uwe Schindler commented on LUCENE-8951: --- Jan, I will take care of ASF Jenkins after lunch. I am not sure about status of [~steve_rowe] and Elasticsearch Jenkins. I hope ASF Jenkins allows bulk changes... Uwe > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929102#comment-16929102 ] Uwe Schindler commented on LUCENE-8951: --- Hi, INFRA-19013 looks like solved, but there were 2 problems: - Jenkins sends all mails with Precendence: bulk and by default all mails using that flag are discarded. This was fixed: According to the docn [1], X means "Do not reject bulk senders, limit size, nor remove parts" - The list had the flag "moderate all subscribers" > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927361#comment-16927361 ] Uwe Schindler commented on LUCENE-8951: --- INFRA-19013 is the jenkins problem > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925476#comment-16925476 ] Uwe Schindler commented on LUCENE-8951: --- The mails by Jenkins are still getting lost. I had no time to keep track. It looks like we need to open an issue and tell them to reconfigure the lists to disable any content filters. Jenkins sends huge mails with various MIME types in multipart/mixed. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists (/) > # Announce to dev@ list that the change will happen (/) > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13746) Apache jenkins needs JVM 11 upgraded to at least 11.0.3 (SSL bugs)
[
https://issues.apache.org/jira/browse/SOLR-13746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924831#comment-16924831
]
Uwe Schindler commented on SOLR-13746:
--
No idea, there is an issue / mail thread already at ASF about AdoptOpenJDK.
I just updated Policeman to 11.0.4 (Linux, Mac, Windows).
> Apache jenkins needs JVM 11 upgraded to at least 11.0.3 (SSL bugs)
> --
>
> Key: SOLR-13746
> URL: https://issues.apache.org/jira/browse/SOLR-13746
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
>
> I just realized that back in June, there was a misscommunication between
> myself & Uwe (and a lack of double checking on my part!) regarding upgrading
> the JVM versions on our jenkins machines...
> *
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/201906.mbox/%3calpine.DEB.2.11.1906181434350.23523@tray%3e]
> *
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/201906.mbox/%3C00b301d52918$d27b2f60$77718e20$@thetaphi.de%3E]
> ...Uwe only updated the JVMs on _his_ policeman jenkins machines - the JVM
> used on the _*apache*_ jenkins nodes is still (as of 2019-09-06)
> "11.0.1+13-LTS" ...
> [https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-master/3689/consoleText]
> {noformat}
> ...
> [java-info] java version "11.0.1"
> [java-info] Java(TM) SE Runtime Environment (11.0.1+13-LTS, Oracle
> Corporation)
> [java-info] Java HotSpot(TM) 64-Bit Server VM (11.0.1+13-LTS, Oracle
> Corporation)
> ...
> {noformat}
> This means that even after the changes made in SOLR-12988 to re-enable SSL
> testing on java11, all Apache jenkins 'master' builds, (including, AFAICT the
> yetus / 'Patch Review' builds) are still SKIPping thousands of tests that use
> SSL (either explicitly, or due to randomization) becauseof the logic in
> SSLTestConfig to detects bad JVM versions an prevent confusion/spurious
> failures.
> We really need to get the jenkins nodes updated to openjdk 11.0.3 or 11.0.4
> ASAP.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8966) KoreanTokenizer should split unknown words on digits
[ https://issues.apache.org/jira/browse/LUCENE-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923335#comment-16923335 ] Uwe Schindler commented on LUCENE-8966: --- Also you are using a private isDigit() at one place, the other place uses Character.isDigit(). This should be consistent. > KoreanTokenizer should split unknown words on digits > > > Key: LUCENE-8966 > URL: https://issues.apache.org/jira/browse/LUCENE-8966 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > Attachments: LUCENE-8966.patch > > > Since https://issues.apache.org/jira/browse/LUCENE-8548 the Korean tokenizer > groups characters of unknown words if they belong to the same script or an > inherited one. This is ok for inputs like Мoscow (with a Cyrillic М and the > rest in Latin) but this rule doesn't work well on digits since they are > considered common with other scripts. For instance the input "44사이즈" is kept > as is even though "사이즈" is part of the dictionary. We should restore the > original behavior and splits any unknown words if a digit is followed by > another type. > This issue was first discovered in > [https://github.com/elastic/elasticsearch/issues/46365] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8966) KoreanTokenizer should split unknown words on digits
[ https://issues.apache.org/jira/browse/LUCENE-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923332#comment-16923332 ] Uwe Schindler commented on LUCENE-8966: --- isNumber() is dead code? > KoreanTokenizer should split unknown words on digits > > > Key: LUCENE-8966 > URL: https://issues.apache.org/jira/browse/LUCENE-8966 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > Attachments: LUCENE-8966.patch > > > Since https://issues.apache.org/jira/browse/LUCENE-8548 the Korean tokenizer > groups characters of unknown words if they belong to the same script or an > inherited one. This is ok for inputs like Мoscow (with a Cyrillic М and the > rest in Latin) but this rule doesn't work well on digits since they are > considered common with other scripts. For instance the input "44사이즈" is kept > as is even though "사이즈" is part of the dictionary. We should restore the > original behavior and splits any unknown words if a digit is followed by > another type. > This issue was first discovered in > [https://github.com/elastic/elasticsearch/issues/46365] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920216#comment-16920216 ] Uwe Schindler edited comment on LUCENE-8951 at 8/31/19 9:23 PM: Hi, INFRA also does not know exactly why the mails are lost. It looks like they are filtered because of non-text or other attachments. The builds@ settings are different from dev@ where also HTML and attachments are allowed. They enabled HTML now, but that was not the issue. Analyzing a mail from jenkins looks like it uses multipart/mixed format: [https://lists.apache.org/api/source.lua/d415bf5c26db91ab17a2b92f664728de9927cd788fc07afd8fd3@%3Cdev.lucene.apache.org%3E] I asked them to enable it. [~humbedooh], any news? was (Author: thetaphi): Hi, INFRA also does not know exactly why the mails are lost. It looks like they are filtered because of non-text or other attachments. The builds@ settings are different from dev@ where also HTML and attachments are allowed. They enabled HTML now, but that was not the issue. Analyzing a mail from jenkins looks like it uses multipart/minxed format: [https://lists.apache.org/api/source.lua/d415bf5c26db91ab17a2b92f664728de9927cd788fc07afd8fd3@%3Cdev.lucene.apache.org%3E] I asked them to enable it. [~humbedooh], any news? > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920216#comment-16920216 ] Uwe Schindler commented on LUCENE-8951: --- Hi, INFRA also does not know exactly why the mails are lost. It looks like they are filtered because of non-text or other attachments. The builds@ settings are different from dev@ where also HTML and attachments are allowed. They enabled HTML now, but that was not the issue. Analyzing a mail from jenkins looks like it uses multipart/minxed format: [https://lists.apache.org/api/source.lua/d415bf5c26db91ab17a2b92f664728de9927cd788fc07afd8fd3@%3Cdev.lucene.apache.org%3E] I asked them to enable it. [~humbedooh], any news? > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918654#comment-16918654 ] Uwe Schindler commented on LUCENE-8951: --- Will do this later as most of them are sleeping. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918492#comment-16918492 ] Uwe Schindler commented on LUCENE-8951: --- I also found no bounces on my company's incoming server. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[
https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918488#comment-16918488
]
Uwe Schindler commented on LUCENE-8951:
---
The Jenkins server already sent several mails, but all got lost (not even
appearing in moderation). It looks like they are swallowed completely. Could it
be that there is some size limit configured on this mailing list (in contrast
to dev@)? Maybe the server drops them because jenkins mails are quite big
because of log files.
This is a failed build and I neither got a mail notification through mailing
list nor any moderation mail:
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24630/console
{noformat}
Aug 29 09:58:05 serv1 postfix/smtpd[8811]: connect from ip6-localhost[::1]
Aug 29 09:58:05 serv1 postfix/smtpd[8811]: 502FE10800C7:
client=ip6-localhost[::1]
Aug 29 09:58:05 serv1 postfix/cleanup[8814]: 502FE10800C7:
message-id=<1214521720.14.1567072685329.javamail.jenk...@serv1.sd-datasolutions.de>
Aug 29 09:58:05 serv1 postfix/qmgr[3889]: 502FE10800C7:
from=, size=105988, nrcpt=1 (queue active)
Aug 29 09:58:05 serv1 postfix/smtpd[8811]: disconnect from ip6-localhost[::1]
ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
Aug 29 09:58:06 serv1 postfix/smtp[8815]: 502FE10800C7:
to=,
relay=mx1-he-de.apache.org[2a01:4f8:c2c:2bf7::1]:25, delay=1.6,
delays=0.1/0/0.22/1.3, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
E24BE7D722)
Aug 29 09:58:06 serv1 postfix/qmgr[3889]: 502FE10800C7: removed
{noformat}
Not sure what happend with that mail! I think we may ask infra on Slack, all
required information to identify that mail should be above.
> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
> # Create mailing lists as an announce only list (/)
> # Subscribe all emails that will be allowed to post (/)
> # Update websites with info about the new lists
> # Announce to dev@ list that the change will happen
> # Modify Jira and Github bots to post to issues@ list instead of dev@
> # Modify Jenkins (including Policeman and other) to post to builds@
> # Announce to dev@ list that the change is effective
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917769#comment-16917769 ] Uwe Schindler commented on LUCENE-8951: --- No idea, ask Infra. Did you get the moderation of my 3rd test mail? > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917666#comment-16917666 ] Uwe Schindler edited comment on LUCENE-8951 at 8/28/19 10:51 AM: - FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive mails, all mail coming in is rejected with some special error code and mailer-daemon message. It's only to send mails (a typing do-dot-reply one). If yozu subscribe it, the ML will remove him asap because of error code. So you must put it on the ALLOW list of the mailing list, not the subscription list. was (Author: thetaphi): FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive mails, all mail coming in is rejected with some special error code and mailer-daemon message. It's only to sent mails (a typing do-dot-reply one). If yozu subscribe it, the ML will remove him asap because of error code. So you must put it on the ALLOW list of the mailing list, not the subscription list. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917666#comment-16917666 ] Uwe Schindler edited comment on LUCENE-8951 at 8/28/19 10:50 AM: - FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive mails, all mail coming in is rejected with some special error code and mailer-daemon message. It's only to sent mails (a typing do-dot-reply one). If yozu subscribe it, the ML will remove him asap because of error code. So you must put it on the ALLOW list of the mailing list, not the subscription list. was (Author: thetaphi): FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive mails, all mail coming in is rejected with some special error code and mailer-daemon message. It's only to sent mails (a typing do-dot-reply one). If yozu subscribe it, the ML will remove him forevwer. So you must put it on the ALLOW list of the mailing list, not the subscription list. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917666#comment-16917666 ] Uwe Schindler commented on LUCENE-8951: --- FYI, please DO NOT SUBSCRIBE jenk...@thetaphi.de This mail cannot receive mails, all mail coming in is rejected with some special error code and mailer-daemon message. It's only to sent mails (a typing do-dot-reply one). If yozu subscribe it, the ML will remove him forevwer. So you must put it on the ALLOW list of the mailing list, not the subscription list. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917661#comment-16917661 ] Uwe Schindler commented on LUCENE-8951: --- I sent another one, I keep it up to your to enable (maybe I have not enough rights on the laist). The CC address of the moderation mail is the the one to allow the sender forever (this is why reply-all works). > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917659#comment-16917659 ] Uwe Schindler commented on LUCENE-8951: --- Hi, I sent a test email, but it went to moderation. I then used replay-all, to put the mail on the allow list of the ML, but it did not help (it sent it to 2 mails, accept-xxx@ and allow-xxx@). I did a 2nd test mail was also stuck in moderation. Maybe somebody has to manually put the mail on the allow list. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications
[ https://issues.apache.org/jira/browse/LUCENE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917637#comment-16917637 ] Uwe Schindler commented on LUCENE-8951: --- OK, I changed Policeman Jenkins. I will send a test e-mail, but before that I will subscribe to both new lists. > Create issues@ and builds@ lists and update notifications > - > > Key: LUCENE-8951 > URL: https://issues.apache.org/jira/browse/LUCENE-8951 > Project: Lucene - Core > Issue Type: Task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > Issue to plan and execute decision from dev mailing list > [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E] > # Create mailing lists as an announce only list (/) > # Subscribe all emails that will be allowed to post (/) > # Update websites with info about the new lists > # Announce to dev@ list that the change will happen > # Modify Jira and Github bots to post to issues@ list instead of dev@ > # Modify Jenkins (including Policeman and other) to post to builds@ > # Announce to dev@ list that the change is effective -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes
[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909691#comment-16909691
]
Uwe Schindler commented on LUCENE-8566:
---
I think as a first step we should change the examples in CustomAnalyzer.
I am +/-0 to deprecate those methods!
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> --
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class factory, String... params)
> - withTokenizer(Class factory,
> Map params)
> - addTokenFilter(Class factory, String...
> params)
> - addTokenFilter(Class factory,
> Map params)
> - addCharFilter(Class factory, String... params)
> - addCharFilter(Class factory,
> Map params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8948) Change "name" argument in ICU factories to "form"
[
https://issues.apache.org/jira/browse/LUCENE-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904615#comment-16904615
]
Uwe Schindler commented on LUCENE-8948:
---
Thanks for adding the nfkc test :-) Nice!
> Change "name" argument in ICU factories to "form"
> -
>
> Key: LUCENE-8948
> URL: https://issues.apache.org/jira/browse/LUCENE-8948
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8948.patch
>
>
> {{o.a.l.a.icu.ICUNormalizer2CharFilterFactory}} and
> {{o.a.l.a.icu.ICUNormalizer2FilterFactory}} have "name" arguments to specify
> Unicode Normalization Form. The "name" is vague and it causes problem with
> SOLR-13593.
> "form" would be suitable here instead of "name".
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904461#comment-16904461
]
Uwe Schindler commented on SOLR-13593:
--
"form" looks fine. Thanks, makes more sense from my standpoint.
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904452#comment-16904452
]
Uwe Schindler commented on SOLR-13593:
--
I tend to break the ICU factory. The name attribute makes no sense to me there
anyways: I was annoyed by it already in Elasticsearch. Name for "What" the hell?
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901888#comment-16901888
]
Uwe Schindler commented on SOLR-13593:
--
Looks good to me! +1
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897164#comment-16897164
]
Uwe Schindler edited comment on SOLR-13658 at 7/31/19 1:17 PM:
---
The var keyword should not bring problems, as it does not mean "unchecked".
Actually it's even more strict! The compiler introduces the exact type of the
right side as the "virtual" type and uses it. So {{var list = new
ArrayList}} introduces as type {{ArrayList}}.
Even more funny, if you use an anonymous subclass, the "var" type is the same
as the internal type of the anonymous subclass (some Foobar$1$2 class)! This
leads to the fact that you can call methods through the "var" type, which are
only defined (public) in the anonymous subclass and not in the class it extends!
As explained before, in contrast to "var" in javascript or "def" in Groovy, the
type is known to the compiler, so there is no risk! There is maybe only
ambiguity if it's not obvious where the type comes from. Famous case: You
SHOULDN'T use diamond operator with var!!! I'd add a regex rule for this
special case (var in combination with diamond on right side).
You also have to know, as "var" is the real native type; you cant assign
something else to a "var" typed variable later on. So if you create an
ArrayList and assign it to a "var" typed variable, it has to stay an ArrayList,
so assigning a different List type won't work. So it's actually more strict! So
when using Interfaces like List and Set, it may often be better to use a real
declaration. Java Champignon Heinz Kabutz tells you: Where you should better
use interfaces (like List), don't use "var" (for the reasons above, the "var"
would be type of concrete class, not interface).
Finally, the var type is not worse than lambdas, they have the same
"automatism". it uses the same semantics. If you forbid "var", you also have to
forbid "lambdas". :-)
was (Author: thetaphi):
The var keyword should not bring problems, as it does not mean "unchecked".
Actually it's even more strict! The compiler introduces the exact type of the
right side as the "virtual" type and uses it. So {{var list = new
ArrayList}} introduces as type {{ArrayList}}.
Even more funny, if you use an anonymous subclass, the "var" type is the same
as the internal type of the anonymous subclass (some Foobar$1$2 class)! This
leads to the fact that you can call methods through the "var" type, which are
only defined (public) in the anonymous subclass and not in the class it extends!
As explained before, in contrast to "var" in javascript or "def" in Groovy, the
type is known to the compiler, so there is no risk! There is maybe only
ambiguity if it's not obvious where the type comes from. Famous case: You
SHOULDN'T use diamond operator with var!!! I'd add a regex rule for this
special case (var in combination with diamond on right side).
You also have to know, as "var" is real the native type; you cant assign
something else to a "var" typed variable later on. So if you create an
ArrayList and assign it to a "var" typed variable, it has to stay an ArrayList,
so assigning a different List type won't work. So it's actually more strict. So
when using Interfaces like List and Set, it may often be better to use a real
declaration. Java Champignon Heinz Kabutz tells you: Where you should better
use interfaces (like List), don't use "var" (for the reasons above, the "var"
would be type of concrete class, not interface).
Finally, the var keyword is not worse than lambdas, they have the same
"automatism". it uses the same semantics. If you forbid "var", you also have to
forbid "lambdas". :-)
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The
[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897164#comment-16897164
]
Uwe Schindler commented on SOLR-13658:
--
The var keyword should not bring problems, as it does not mean "unchecked".
Actually it's even more strict! The compiler introduces the exact type of the
right side as the "virtual" type and uses it. So {{var list = new
ArrayList}} introduces as type {{ArrayList}}.
Even more funny, if you use an anonymous subclass, the "var" type is the same
as the internal type of the anonymous subclass (some Foobar$1$2 class)! This
leads to the fact that you can call methods through the "var" type, which are
only defined (public) in the anonymous subclass and not in the class it extends!
As explained before, in contrast to "var" in javascript or "def" in Groovy, the
type is known to the compiler, so there is no risk! There is maybe only
ambiguity if it's not obvious where the type comes from. Famous case: You
SHOULDN'T use diamond operator with var!!! I'd add a regex rule for this
special case (var in combination with diamond on right side).
You also have to know, as "var" is real the native type; you cant assign
something else to a "var" typed variable later on. So if you create an
ArrayList and assign it to a "var" typed variable, it has to stay an ArrayList,
so assigning a different List type won't work. So it's actually more strict. So
when using Interfaces like List and Set, it may often be better to use a real
declaration. Java Champignon Heinz Kabutz tells you: Where you should better
use interfaces (like List), don't use "var" (for the reasons above, the "var"
would be type of concrete class, not interface).
Finally, the var keyword is not worse than lambdas, they have the same
"automatism". it uses the same semantics. If you forbid "var", you also have to
forbid "lambdas". :-)
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class
[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[
https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897097#comment-16897097
]
Uwe Schindler commented on SOLR-13658:
--
You can only check this via regex in source code. The "var" keyword (it's
actually NOT a keyword according to the language spec, which is a funny detail)
is nowhere in class files, so forbiddenapis cannot see those.
> Discuss adding the new "var" construct to the forbidden API list.
> -
>
> Key: SOLR-13658
> URL: https://issues.apache.org/jira/browse/SOLR-13658
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Personally, I'm strongly against allowing the "var" construct in Lucene/Solr
> code. I think it's a wonderful opportunity to introduce bugs that won't be
> found until runtime as well as making maintainence significantly harder. I
> don't even think for a project like Solr it would save any time overall...
> So let's discuss this ahead of time and see if we can reach a consensus. I'll
> start the discussion off:
> My baseline argument is that for a large complex project, especially ones
> with many different people coding, I want the compiler to give me all the
> help possible. And the "var" construct takes away some of that help.
> I’ve seen this argument go around at least 4 times in my career. The argument
> that “it takes longer to write if you have to type all this stuff” is bogus.
> Last I knew, 80% of the time spent is in maintaining/reading it. So the
> argument “I can write faster” means I can save some fraction of the 20% of
> the time writing the original code but spend many times that figuring out
> what the code is actually doing the other 80% of the time.
> The IDE makes _writing_ this slightly faster, admittedly.
> {code:java}
> Whatever what = new Whatever();
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> {code}
> But once that’s done, if I’m reading the code again I don't have any clue what
> {code:java}
> kidding or blivet
> {code}
> are. Here's the signature for getComplex:
> {code:java}
> Map> getComplex()
> {code}
> I have to go over to the definition (which I admit is easier than it used to
> be in the bad old days, but still) to find out.
> HERE'S THE PART I REALLY OBJECT TO!
> The above I could probably live with, maybe we could get the InteliJ
> developers and see if they can make hover show the inference. What I will
> kick and scream about is introducing bugs that are not found until runtime.
> Even this obvious stupidity fails with a ClassCastException:
> {code:java}
> var corny = new TreeMap();
> corny.put("one", "two");
> corny.get(1);
> {code}
> But it's much worse when using classes from somewhere else. For instance,
> change the underlying class in the first example to return
> {code:java}
> Map>{code}
> .
> This code that used to work now throws an error, _but it compiles_.
> {code:java}
> var kidding = what.getComplex();
> var blivet = kidding.get("stuff");
> var blah = kidding.get("stuff").get(1); // generates ClassCastException:
> class java.lang.String cannot be cast to class java.lang.Integer
> {code}
> So in order to save some time writing (that I claim will be lost multiple
> times over when maintaining the code) we'll introduce run-time errors that
> will take a bunch _more_ time to figure out, and won’t be found during unit
> tests unless and until we have complete code coverage.
> If there's a way to insure that this kind of thing can't get into the code
> and we implement that, I could be persuaded, but let's make that an explicit
> requirement (and find a suitable task for the build system, precommit or
> whatever).
> The floor is open...
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885010#comment-16885010 ] Uwe Schindler commented on LUCENE-8911: --- Hi [~tomoko], sorry for the delay (was in "weekend mode"). The changes look fine, that's exactly how I thought about it. It's good that the original names is only modified if the legacy name is not yet in the map, so we don't get duplicate names with just different spelling. Just to confirm: The generated names are all lower case, right? So if there is a factory with no NAME field, it would produce a lowercase only entry in both (map and set). +1 Should we get this into 8.2 or not? > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13631) Java 11 date parsing causing NPEs
[
https://issues.apache.org/jira/browse/SOLR-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16884627#comment-16884627
]
Uwe Schindler commented on SOLR-13631:
--
This is for sure be caused by the fact that some Linux distributions using a
different type of timezone data file shared with other packages. That's a
antipattern but still done by some of them. I think Ubuntu gave up on this.
You'd open an issue at the distribution, showing this with a simple test case.
This is not a problem if Lucene.
> Java 11 date parsing causing NPEs
> -
>
> Key: SOLR-13631
> URL: https://issues.apache.org/jira/browse/SOLR-13631
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
>
> Across all my machines with Fedora 30, I encounter 20+ test failures on
> master with the following NPEs. Same when starting Solr (it doesn't start up).
> {code}
>[junit4] 2> Caused by: java.time.format.DateTimeParseException: Text
> '2019-07-14T07:09:13.341Z' could not be parsed: null
>[junit4] 2> at
> java.base/java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:2017)
>[junit4] 2> at
> java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1920)
>[junit4] 2> at
> org.apache.solr.update.processor.ParseDateFieldUpdateProcessorFactory.parseInstant(ParseDateFieldUpdateProcessorFactory.java:230)
>[junit4] 2> at
> org.apache.solr.update.processor.ParseDateFieldUpdateProcessorFactory.validateFormatter(ParseDateFieldUpdateProcessorFactory.java:214)
>[junit4] 2> ... 44 more
> {code}
> Here are my environment details:
> OS: Fedora 30
> Java version:
> {code}
> [ishan@chromebox core] $ java -version
> openjdk version "11.0.3" 2019-04-16
> OpenJDK Runtime Environment 18.9 (build 11.0.3+7)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7, mixed mode, sharing)
> {code}
> Kernel: 5.1.16-300.fc30.x86_64
> JDK was installed via "sudo dnf install java-11-openjdk-devel".
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883839#comment-16883839 ] Uwe Schindler commented on LUCENE-8911: --- This would not add any complexity, only at the place where the SPIIterator is consumed you have 2 "adds" to the Map. One for the name field and a second one for the "legacy" name if it's not already there. Anywhere else no changes. > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883802#comment-16883802 ] Uwe Schindler edited comment on LUCENE-8911 at 7/12/19 1:22 PM: I would not strictly enforce the old naming rules, because the idea behind the NAME field is that the developer of a TokenStream component can decide for a good name that unrelated to class name. E.g., this allows to restructure your classes. The new design was from the beginning made in a way that it's perfectly possible to assign "alias" names for tokenstream components in the future. E.g., we could deprecate an old name and rename something and temporary keep both names for lookup. The NAME field only contains the new one. This is basically the same: Let the developer decide for the name that fit's best for his need. For backwards compatibility just keep the old name. For Solr that's not an issue, as old schemas use class names anyways. For Lucene-Internal components tis is not a problem, as we kept the old names - but I'd like to possibly have the option to rename some of those in the future! was (Author: thetaphi): I would not strictly enforce the old naming rules, because the idea behind the NAME field is that the developer of a TokenStream component can decide for a good name that unrelated to class name. E.g., this allows to restructure your classes. The new design was from the beginning made in a way that it's perfectly possible to assign "alias" names for tokenstream components in the future. E.g., we could deprecate an old name and rename something and temporary keep both names for lookup. The NAME field only contains the new one. This is basically the same: Let the developer decide for the name that fit's best for his need. For backwards compatibility just keep the old name. For Lucene-Internal components tis is not a problem, as we kept the old names - but I'd like to possibly have the option to rename some of those in the future! > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883802#comment-16883802 ] Uwe Schindler commented on LUCENE-8911: --- I would not strictly enforce the old naming rules, because the idea behind the NAME field is that the developer of a TokenStream component can decide for a good name that unrelated to class name. E.g., this allows to restructure your classes. The new design was from the beginning made in a way that it's perfectly possible to assign "alias" names for tokenstream components in the future. E.g., we could deprecate an old name and rename something and temporary keep both names for lookup. The NAME field only contains the new one. This is basically the same: Let the developer decide for the name that fit's best for his need. For backwards compatibility just keep the old name. For Lucene-Internal components tis is not a problem, as we kept the old names - but I'd like to possibly have the option to rename some of those in the future! > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883689#comment-16883689 ] Uwe Schindler commented on LUCENE-8911: --- And Solr should log a schema warning (Lucene can't do this). > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883687#comment-16883687
]
Uwe Schindler edited comment on LUCENE-8911 at 7/12/19 9:52 AM:
My opinion/idea would be the following:
- Backport everything to 8.x
- In addition to extracting the {{NAME}} field (which should not fail the SPI
lookup) also generate the "old name". Add both names to the map (they may
differ, if a user decides to use his own name).
This would bring both worlds:
- Old factories still work (using the old algorithm) to generate the name
- New factories would have both names (ideally they should not differ, but with
the new aproach the user should be able to decide for his own name, not
generated from the factory class name).
We should add a test with a fake factory (maybe add a META-INF file to the
tests) without NAME to test backwards compatibility.
was (Author: thetaphi):
My opinion/idea would be the following:
- Backport everything to 8.x
- In addition to extracting the {{NAME}} field (which should not fail the
build) also generate the "old name". Add both names to the map (they may
differ, if a user decides to use his own name).
This would bring both worlds:
- Old factories still work (using the old algorithm) to generate the name
- New factories would have both names (ideally they should not differ, but with
the new aproach the user should be able to decide for his own name, not
generated from the factory class name).
We should add a test with a fake factory (maybe add a META-INF file to the
tests) without NAME to test backwards compatibility.
> Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
> -
>
> Key: LUCENE-8911
> URL: https://issues.apache.org/jira/browse/LUCENE-8911
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
>
> In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch.
> Can we backport it to 8x branch again, with transparent backwards
> compatibility (by emulating the factory loading method of Lucene 8.1)?
> I am not so sure about it would be better or not to backport the changes,
> however, maybe it is good for Solr to have SOLR-13593 without waiting for
> release 9.0.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883687#comment-16883687
]
Uwe Schindler commented on LUCENE-8911:
---
My opinion/idea would be the following:
- Backport everything to 8.x
- In addition to extracting the {{NAME}} field (which should not fail the
build) also generate the "old name". Add both names to the map (they may
differ, if a user decides to use his own name).
This would bring both worlds:
- Old factories still work (using the old algorithm) to generate the name
- New factories would have both names (ideally they should not differ, but with
the new aproach the user should be able to decide for his own name, not
generated from the factory class name).
We should add a test with a fake factory (maybe add a META-INF file to the
tests) without NAME to test backwards compatibility.
> Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
> -
>
> Key: LUCENE-8911
> URL: https://issues.apache.org/jira/browse/LUCENE-8911
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
>
> In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch.
> Can we backport it to 8x branch again, with transparent backwards
> compatibility (by emulating the factory loading method of Lucene 8.1)?
> I am not so sure about it would be better or not to backport the changes,
> however, maybe it is good for Solr to have SOLR-13593 without waiting for
> release 9.0.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8907) Provide backward compatibility for loading analysis factories
[ https://issues.apache.org/jira/browse/LUCENE-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16882309#comment-16882309 ] Uwe Schindler commented on LUCENE-8907: --- I agree partly with Adrien. But we can still allow to use old factories in 8.2, in a lenient way: If the factory has no NAME field, it generates one using old algorithm - and ideally would log a warning. The biggest problem ist that we can't log warnings, which is not good. Solr could do this. Sorry for coming up with this issue so late, but I did not notice that the whole change was committed to 8.x. I have here a customer project with many custom analyzers, so it came to my mind. > Provide backward compatibility for loading analysis factories > - > > Key: LUCENE-8907 > URL: https://issues.apache.org/jira/browse/LUCENE-8907 > Project: Lucene - Core > Issue Type: Task > Components: modules/analysis >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Blocker > > The changes in LUCENE-8778 have breaking changes in the analysis factory > interface and custom factories implemented by users / 3rd parties will be > affected. We need to keep some backwards compatibility during 8.x. > Please see the discussion in SOLR-13593 for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881868#comment-16881868
]
Uwe Schindler commented on SOLR-13593:
--
Hi, I am not fully sure how to handle that in 8.x. I just know that custom
analyzers and token filters is one of the most often implemented external
stuff, so we should at least keep some backwards compatibility.
Sorry for being that late, I just noticed the backport and then slept a few
nights about it. Maybe let's open a separate LUCENE issue about this.
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881845#comment-16881845
]
Uwe Schindler commented on SOLR-13593:
--
While thinking about the next 8.x release: Actually because of the
Lucene-change we already have a backwards-incompatible change in Lucene: If you
implemented your own factory classes, you have to add the "NAME" field,
otherwise the factory and (I think) all other factories won't initialize! This
means that it may happen that somebody has an old JAR file with 3rd party
analyzers in classpath and this fails to load the whole analyzer factory,
making Solr unusable.
Maybe in 8.x we need some "transparent" backwards compatibility, so
"incomplete" factories won't hurt loading the SPI framework, or we just emulate
the old name. Should I maybe open another issue about this. Curretly I am a bit
afraid of releasing the new factory interface without a migration path.
For 9.0 all is fine.
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881841#comment-16881841
]
Uwe Schindler commented on SOLR-13593:
--
Changes look good. I think we can commit this separately and change the
example/default schemas later.
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878426#comment-16878426
]
Uwe Schindler commented on SOLR-13593:
--
Hi,
I am not so happy about the "spi" name, I'd perfer "name". Whats's exactly the
problem with using "name"? The Solr plugin stuff should not be affected by this.
Another suggestion, not sure if it's already implemented: When persisting a
managed schema after modification, it should use the provider names only and no
longer persist class names.
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8865) Use incoming thread for execution if IndexSearcher has an executor
[ https://issues.apache.org/jira/browse/LUCENE-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868508#comment-16868508 ] Uwe Schindler commented on LUCENE-8865: --- Using Executor is also much better if you want a completely different type of thread pool. Having the most abstract and simple interface for submitting/executing jobs is nice. > Use incoming thread for execution if IndexSearcher has an executor > --- > > Key: LUCENE-8865 > URL: https://issues.apache.org/jira/browse/LUCENE-8865 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Simon Willnauer >Priority: Major > Fix For: master (9.0), 8.2 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Today we don't utilize the incoming thread for a search when IndexSearcher > has an executor. This thread is only idleing but can be used to execute a > search > once all other collectors are dispatched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8865) Use incoming thread for execution if IndexSearcher has an executor
[ https://issues.apache.org/jira/browse/LUCENE-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866073#comment-16866073 ] Uwe Schindler commented on LUCENE-8865: --- +1 > Use incoming thread for execution if IndexSearcher has an executor > --- > > Key: LUCENE-8865 > URL: https://issues.apache.org/jira/browse/LUCENE-8865 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Simon Willnauer >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > Today we don't utilize the incoming thread for a search when IndexSearcher > has an executor. This thread is only idleing but can be used to execute a > search > once all other collectors are dispatched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864153#comment-16864153 ] Uwe Schindler commented on SOLR-13452: -- [~markrmil...@gmail.com]: I am not even sure if we need the test and the VirtualMethod class at all. I think it's dead code. We had it for backwards compatibility hack at several places. I don't think its used anymore. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8847) Code Cleanup: Rewrite StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860118#comment-16860118 ] Uwe Schindler edited comment on LUCENE-8847 at 6/10/19 4:27 PM: I cherry picked the commit to branch_8x. Will do the usual maintenance checks to ensure nothing breaks. At least it applied cleanly. was (Author: thetaphi): I cherry picket the commit to branch_8x. Will do the usual maintenance checks to ensure notihing breaks. At least it applied cleanly. > Code Cleanup: Rewrite StringBuilder.append with concatted strings > - > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Fix For: master (9.0), 8.2 > > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8847) Code Cleanup: Rewrite StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-8847. --- Resolution: Fixed Fix Version/s: 8.2 Thanks [~KoenDG] > Code Cleanup: Rewrite StringBuilder.append with concatted strings > - > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Fix For: master (9.0), 8.2 > > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8847) Code Cleanup: Rewrite StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860118#comment-16860118 ] Uwe Schindler commented on LUCENE-8847: --- I cherry picket the commit to branch_8x. Will do the usual maintenance checks to ensure notihing breaks. At least it applied cleanly. > Code Cleanup: Rewrite StringBuilder.append with concatted strings > - > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Fix For: master (9.0) > > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8847) Code Cleanup: Rewrite StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-8847: -- Summary: Code Cleanup: Rewrite StringBuilder.append with concatted strings (was: Code Cleanup: Remove StringBuilder.append with concatted strings) > Code Cleanup: Rewrite StringBuilder.append with concatted strings > - > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Fix For: master (9.0) > > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8847) Code Cleanup: Remove StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860104#comment-16860104 ] Uwe Schindler commented on LUCENE-8847: --- If it's about something else, open a new issue. I already changed the issue subject to clarify what it's doing. The pull requests are just part of an issue, normally they won't be mentioned in the changes list. JIRA: If it's something about Lucene and Solr, use LUCENE; if it's only about Solr, open in SOLR. > Code Cleanup: Remove StringBuilder.append with concatted strings > > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Fix For: master (9.0) > > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8847) Code Cleanup: Remove StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860097#comment-16860097 ] Uwe Schindler commented on LUCENE-8847: --- You can call it as often as possible. For this case, the changes entry should only go into Lucene with the new issue number LUCENE-8847. Solr won't mention this change as at the beginning of the changes file it refers to Lucene changes anyways. > Code Cleanup: Remove StringBuilder.append with concatted strings > > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Fix For: master (9.0) > > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8847) Code Cleanup: Remove StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860098#comment-16860098 ] Uwe Schindler commented on LUCENE-8847: --- What do you mean with multiple PRs? Here is only one PR and only one issue number. > Code Cleanup: Remove StringBuilder.append with concatted strings > > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Fix For: master (9.0) > > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8847) Code Cleanup: Remove StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-8847: -- Labels: (was: performance) > Code Cleanup: Remove StringBuilder.append with concatted strings > > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8847) Code Cleanup: Remove StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-8847: -- Fix Version/s: master (9.0) > Code Cleanup: Remove StringBuilder.append with concatted strings > > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Fix For: master (9.0) > > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8847) Code Cleanup: Remove StringBuilder.append with concatted strings
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-8847: -- Summary: Code Cleanup: Remove StringBuilder.append with concatted strings (was: Code Cleanup - Performance) > Code Cleanup: Remove StringBuilder.append with concatted strings > > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Labels: performance > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8847) Code Cleanup - Performance
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-8847: - Assignee: Uwe Schindler > Code Cleanup - Performance > -- > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Assignee: Uwe Schindler >Priority: Trivial > Labels: performance > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8847) Code Cleanup - Performance
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860075#comment-16860075 ] Uwe Schindler commented on LUCENE-8847: --- I moved this ticket to Lucene. Issues affecting both projects should better be opened in Lucene, especially as this ticket mainly talks about Lucene's code. > Code Cleanup - Performance > -- > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Priority: Trivial > Labels: performance > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Deleted] (LUCENE-8846) Code Cleanup - Performance
[ https://issues.apache.org/jira/browse/LUCENE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler deleted LUCENE-8846: -- > Code Cleanup - Performance > -- > > Key: LUCENE-8846 > URL: https://issues.apache.org/jira/browse/LUCENE-8846 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Priority: Trivial > > Complementary ticket for this: > https://issues.apache.org/jira/browse/SOLR-13533 > > As stated in the other ticket, please don't review this using time you'd > normally spend on working hours. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Moved] (LUCENE-8847) Code Cleanup - Performance
[ https://issues.apache.org/jira/browse/LUCENE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler moved SOLR-13533 to LUCENE-8847: -- Security: (was: Public) Lucene Fields: New Key: LUCENE-8847 (was: SOLR-13533) Project: Lucene - Core (was: Solr) > Code Cleanup - Performance > -- > > Key: LUCENE-8847 > URL: https://issues.apache.org/jira/browse/LUCENE-8847 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Koen De Groote >Priority: Trivial > Labels: performance > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13533) Code Cleanup - Performance
[ https://issues.apache.org/jira/browse/SOLR-13533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859926#comment-16859926 ] Uwe Schindler commented on SOLR-13533: -- More info: - Spec: https://openjdk.java.net/jeps/280 - Elasticsearch painless concat: https://github.com/elastic/elasticsearch/blob/ad2e9faa7edfd9acc60d8ad1462c2cfad6eee76e/modules/lang-painless/src/main/java/org/elasticsearch/painless/MethodWriter.java#L270-L324 > Code Cleanup - Performance > -- > > Key: SOLR-13533 > URL: https://issues.apache.org/jira/browse/SOLR-13533 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Koen De Groote >Priority: Trivial > Labels: performance > > EDIT: Again, to clarify, please don't bother yourself with this ticket on > company time, on personal time you could be working on something that makes > you money or improves the product for your feature personally. > > This entire ticket is an afterthough. A look back at the code base that most > people don't have the time for. > - > > Code cleanup as suggested by static analysis tools. Will be done in my spare > time. > If someone reviews this, please also do not take up actual time from your > work to do that. I do not wish to take away from your working hours. > > These are simple, trivial things, that were probably overlooked or not even > considered(which isn't an accusation or something negative). But also stuff > that the Java compiler/JIT won't optimize on its own. > > That's what static analysis tool are good for: picking stuff like that up. > > I'm talking about Intellij's static code analysis. Facebook's "Infer" for > Java. Google's "errorprone", etc... > These are the kinds of things that, frankly, for the people actually working > on real features, are very time consuming, not even part of the feature, and > have a very low chance of actually turning up a real performance issue. > So I'm opting to have a look at the results of these tools and implementing > the sensible stuff and if something bigger pops up I'll make a separate > ticket for those things individually. > > Creating this ticket so I can name a branch after it. > > The only questions I have are: since the code base is so large, do I apply > each subject to all parts of it? Or only core? How do I split it up? > Do I make multiple PRs with this one ticket? Or do I make multiple tickets > and give each their own PR? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13533) Code Cleanup - Performance
[
https://issues.apache.org/jira/browse/SOLR-13533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859925#comment-16859925
]
Uwe Schindler commented on SOLR-13533:
--
Hi,
I am fine with this patch, except for tests. They should not be "optimized"
(although it's no longer a required optimization, see below).
{quote}
So, something like:
StringBuilder sb = new StringBuilder();
sb.append("Hello, " + "World!");
Which defeats the very purpose of using a StringBuilder. And also it causes the
internal construction of extra StringBuilder objects by the JVM. And the JVM is
very conservative with that optimization. It does no interpretation, no
recognizing that there is already a StringBuilder present and adding it to that
one.
It is true that for simple concatentation, StringBuilder isn't required. But
when it is already being used, then using append for everything is the best
option.
{quote}
This is not quite true anymore. Lucene + Solr master is on Java 11 already, so
the class files are compiled for Java 11 and have target Java 11. This means,
simple string concats no longer use a StringBuilder internally. In fact, if you
concat a lot of stuff with static components like fragments and numbers, it's
now better to use string concats instead of StringBuilders. StringBuilders
should only be used for loops or if/then/else constructs.
Starting from Java 9, the "+" operator no longer uses StringBuilder and uses
instead the new feature "indyfied string concat" (which is BTW also used by
Elasticsearch in its painless scripting engine). What happens is that it
collects all static parts of the concat in to a static constant pool entry not
even passed to the method call, but part of the invokedynamic signature and the
remaining dynamic parts are pushed to stack as is. This allows to highly
optimize the string concats, which are only one single method call solely
containing the dynamic parts to a prepared MethodHandle that contains all
static parts.
So we should also review our string concats with StringBuilder and if they
don't use if/then/else and loops, replace them by "+".
> Code Cleanup - Performance
> --
>
> Key: SOLR-13533
> URL: https://issues.apache.org/jira/browse/SOLR-13533
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Koen De Groote
>Priority: Trivial
> Labels: performance
>
> EDIT: Again, to clarify, please don't bother yourself with this ticket on
> company time, on personal time you could be working on something that makes
> you money or improves the product for your feature personally.
>
> This entire ticket is an afterthough. A look back at the code base that most
> people don't have the time for.
> -
>
> Code cleanup as suggested by static analysis tools. Will be done in my spare
> time.
> If someone reviews this, please also do not take up actual time from your
> work to do that. I do not wish to take away from your working hours.
>
> These are simple, trivial things, that were probably overlooked or not even
> considered(which isn't an accusation or something negative). But also stuff
> that the Java compiler/JIT won't optimize on its own.
>
> That's what static analysis tool are good for: picking stuff like that up.
>
> I'm talking about Intellij's static code analysis. Facebook's "Infer" for
> Java. Google's "errorprone", etc...
> These are the kinds of things that, frankly, for the people actually working
> on real features, are very time consuming, not even part of the feature, and
> have a very low chance of actually turning up a real performance issue.
> So I'm opting to have a look at the results of these tools and implementing
> the sensible stuff and if something bigger pops up I'll make a separate
> ticket for those things individually.
>
> Creating this ticket so I can name a branch after it.
>
> The only questions I have are: since the code base is so large, do I apply
> each subject to all parts of it? Or only core? How do I split it up?
> Do I make multiple PRs with this one ticket? Or do I make multiple tickets
> and give each their own PR?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8811) Add maximum clause count check to IndexSearcher rather than BooleanQuery
[ https://issues.apache.org/jira/browse/LUCENE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858669#comment-16858669 ] Uwe Schindler commented on LUCENE-8811: --- This is why I am asking. I had a project and I implemented several visitors. And neither the documentation nor the behavior looks consistent. From my understanding, visitLeaf is called for every query you see. And visitTerms additionally if there are terms. Check the code, Query.visit by default always calls with itself and then delegates to a protected method. > Add maximum clause count check to IndexSearcher rather than BooleanQuery > > > Key: LUCENE-8811 > URL: https://issues.apache.org/jira/browse/LUCENE-8811 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-8811.patch, LUCENE-8811.patch, LUCENE-8811.patch, > LUCENE-8811.patch, LUCENE-8811.patch > > > Currently we only check whether boolean queries have too many clauses. > However there are other ways that queries may have too many clauses, for > instance if you have boolean queries that have themselves inner boolean > queries. > Could we use the new Query visitor API to move this check from BooleanQuery > to IndexSearcher in order to make this check more consistent across queries? > See for instance LUCENE-8810 where a rewrite rule caused the maximum clause > count to be hit even though the total number of leaf queries remained the > same. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8811) Add maximum clause count check to IndexSearcher rather than BooleanQuery
[ https://issues.apache.org/jira/browse/LUCENE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858655#comment-16858655 ] Uwe Schindler commented on LUCENE-8811: --- I am not sure if it's correct to count in both visitTerms and visitLeafs. Would this not count 2 times? The main query is counted anyways because visit() calls the visitor's visitLeaf, so the clause is counted. > Add maximum clause count check to IndexSearcher rather than BooleanQuery > > > Key: LUCENE-8811 > URL: https://issues.apache.org/jira/browse/LUCENE-8811 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-8811.patch, LUCENE-8811.patch, LUCENE-8811.patch, > LUCENE-8811.patch, LUCENE-8811.patch > > > Currently we only check whether boolean queries have too many clauses. > However there are other ways that queries may have too many clauses, for > instance if you have boolean queries that have themselves inner boolean > queries. > Could we use the new Query visitor API to move this check from BooleanQuery > to IndexSearcher in order to make this check more consistent across queries? > See for instance LUCENE-8810 where a rewrite rule caused the maximum clause > count to be hit even though the total number of leaf queries remained the > same. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8811) Add maximum clause count check to IndexSearcher rather than BooleanQuery
[ https://issues.apache.org/jira/browse/LUCENE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858657#comment-16858657 ] Uwe Schindler commented on LUCENE-8811: --- Otherwise it's a great idea to use visitors. > Add maximum clause count check to IndexSearcher rather than BooleanQuery > > > Key: LUCENE-8811 > URL: https://issues.apache.org/jira/browse/LUCENE-8811 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-8811.patch, LUCENE-8811.patch, LUCENE-8811.patch, > LUCENE-8811.patch, LUCENE-8811.patch > > > Currently we only check whether boolean queries have too many clauses. > However there are other ways that queries may have too many clauses, for > instance if you have boolean queries that have themselves inner boolean > queries. > Could we use the new Query visitor API to move this check from BooleanQuery > to IndexSearcher in order to make this check more consistent across queries? > See for instance LUCENE-8810 where a rewrite rule caused the maximum clause > count to be hit even though the total number of leaf queries remained the > same. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848161#comment-16848161
]
Uwe Schindler commented on LUCENE-8778:
---
Instead of slowing down the case-insensitive lookup, I'd just handle a Set with
the original names (for reference), but do the lookup on the lowercased map.
You just have to be sure that you don't generate duplicates.
I would like to have the documented names preserving their original case,
deduplicate those and lowercase them for lookup map. Also check that size of
map and size of set are identical. In addition document that the lookup is
case-insensitive (which it always was).
Another idea I had was to allow "multiple names" for same component (to allow
compatibility with Elasticsearch). But I am not sure if this is worth. If
Elasticsearch moves to "our" names, they should keep a legacy mapping
internally.
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: ListAnalysisComponents.java, SPINamesGenerator.java,
> Screenshot from 2019-04-26 02-17-48.png, TestSPINames.java
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846110#comment-16846110
]
Uwe Schindler commented on LUCENE-8778:
---
Hi Tomoko, from my persepctive this looks fine.
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: SPINamesGenerator.java, Screenshot from 2019-04-26
> 02-17-48.png
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-8807.
---
Resolution: Fixed
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{\*build.xml}} and
> {{\*ivy\*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844988#comment-16844988
]
Uwe Schindler commented on LUCENE-8807:
---
I also nuked ivy caches on policeman jenkins to have a fresh build there.
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{\*build.xml}} and
> {{\*ivy\*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8807:
--
Description:
At least for Lucene this is not a security issue, because we have checksums for
all downloaded JAR dependencies:
{quote}
[...] Projects like Lucene do checksum whitelists of
all their build dependencies, and you may wish to consider that as a
protection against threats beyond just MITM [...]
{quote}
This patch fixes the URLs for most files referenced in {{\*build.xml}} and
{{\*ivy\*.xml}} to HTTPS. There are a few data files in benchmark which use
HTTP only, but that's uncritical and I added a TODO. Some were broken already.
I removed the "uk.maven.org" workarounds for Maven, as this does not work with
HTTPS. By keeping those inside, we break the whole chain of trust, as any
non-working HTTPS would fallback to the insecure uk.maven.org Maven mirror.
As the great chinese firewall is changing all the time, we should just wait for
somebody complaining.
was:
At least for Lucene this is not a security issue, because we have checksums for
all downloaded JAR dependencies:
{quote}
[...] Projects like Lucene do checksum whitelists of
all their build dependencies, and you may wish to consider that as a
protection against threats beyond just MITM [...]
{quote}
This patch fixes the URLs for most files referenced in {{*build.xml}} and
{{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use HTTP
only, but that's uncritical and I added a TODO. Some were broken already.
I removed the "uk.maven.org" workarounds for Maven, as this does not work with
HTTPS. By keeping those inside, we break the whole chain of trust, as any
non-working HTTPS would fallback to the insecure uk.maven.org Maven mirror.
As the great chinese firewall is changing all the time, we should just wait for
somebody complaining.
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{\*build.xml}} and
> {{\*ivy\*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8807:
--
Description:
At least for Lucene this is not a security issue, because we have checksums for
all downloaded JAR dependencies:
{quote}
[...] Projects like Lucene do checksum whitelists of
all their build dependencies, and you may wish to consider that as a
protection against threats beyond just MITM [...]
{quote}
This patch fixes the URLs for most files referenced in {{*build.xml}} and
{{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use HTTP
only, but that's uncritical and I added a TODO. Some were broken already.
I removed the "uk.maven.org" workarounds for Maven, as this does not work with
HTTPS. By keeping those inside, we break the whole chain of trust, as any
non-working HTTPS would fallback to the insecure uk.maven.org Maven mirror.
As the great chinese firewall is changing all the time, we should just wait for
somebody complaining.
was:
At least for Lucene this is not a security issue, because we have checksums for
all downloaded JAR dependencies, but ASF asked all projects to ensure that
download URLs for dependencies are using HTTPS:
{quote}
[...] Projects like Lucene do checksum whitelists of
all their build dependencies, and you may wish to consider that as a
protection against threats beyond just MITM [...]
{quote}
This patch fixes the URLs for most files referenced in {{*build.xml}} and
{{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use HTTP
only, but that's uncritical and I added a TODO. Some were broken already.
I removed the "uk.maven.org" workarounds for Maven, as this does not work with
HTTPS. By keeping those inside, we break the whole chain of trust, as any
non-working HTTPS would fallback to the insecure uk.maven.org Maven mirror.
As the great chinese firewall is changing all the time, we should just wait for
somebody complaining.
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844903#comment-16844903
]
Uwe Schindler commented on LUCENE-8807:
---
bq. Should be https instead of http2
Fixed locally. Thanks.
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8807:
--
Attachment: (was: LUCENE-8807.patch)
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8807:
--
Attachment: LUCENE-8807.patch
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844871#comment-16844871
]
Uwe Schindler commented on LUCENE-8807:
---
I changed the Ivy URL of mecab-naist-jdic, as the redirector was using HTTP
again, this one works:
https://rwthaachen.dl.osdn.jp/naist-jdic/53500/mecab-naist-jdic-0.6.3b-20111013.tar.gz
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8807:
--
Attachment: LUCENE-8807.patch
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844866#comment-16844866
]
Uwe Schindler commented on LUCENE-8807:
---
I am so annoyed, if I send them a mail or open issue, it would be a policeman
like one...
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844864#comment-16844864
]
Uwe Schindler edited comment on LUCENE-8807 at 5/21/19 2:02 PM:
FYI, the maven.restlet.org stuff annoyed me a lot: They changed from
restlet.org to restlet.com. But the HTTPS one at https://maven.restlet.org
redirected to the insecure http://maven.restlet.com which is a disallowed
action and Ivy disallows this (of course). This took me half an hour of CURL
debugging to understand the issue. Somebody should tell those - that's
incredible!
was (Author: thetaphi):
FYI, the maven.restlet.org stuff annoyed me a lot: They changed from
restlet.org to restlet.com. But the HTTPS one at https://maven.restlet.org
redirected to the insecure http://maven.restlet.com which is a disallowed
action and Ivy disallows this (of course). This took me half an hour to
understand the issue. Somebody should tell those - that's incredible!
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844864#comment-16844864
]
Uwe Schindler commented on LUCENE-8807:
---
FYI, the maven.restlet.org stuff annoyed me a lot: They changed from
restlet.org to restlet.com. But the HTTPS one at https://maven.restlet.org
redirected to the insecure http://maven.restlet.com which is a disallowed
action and Ivy disallows this (of course). This took me half an hour to
understand the issue. Somebody should tell those - that's incredible!
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8807:
--
Fix Version/s: 7.7.2
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844855#comment-16844855
]
Uwe Schindler commented on LUCENE-8807:
---
I would like to push this soon to master, 8.x and the soon to be released
bugfix versions. Please wait a bit with starting the release process.
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8807:
--
Priority: Blocker (was: Major)
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844854#comment-16844854
]
Uwe Schindler commented on LUCENE-8807:
---
I also checked the new JAR checksums after the change with "ant jar-checksums"
after refreshing everything. No SHA1 changes.
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844852#comment-16844852
]
Uwe Schindler commented on LUCENE-8807:
---
Patch: [^LUCENE-8807.patch]
I tested this:
- Nuked whole IVY cache and ran "ant resolve".
- Rebuild kuromoji
- ran "ant ivy-bootstrap" after deleting the file
- downloaded some benchmark files (although the benchmark mdoules documentation
how to get data files is not existent...)
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8807:
--
Attachment: LUCENE-8807.patch
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8807) Change all download URLs in build files to HTTPS
Uwe Schindler created LUCENE-8807:
-
Summary: Change all download URLs in build files to HTTPS
Key: LUCENE-8807
URL: https://issues.apache.org/jira/browse/LUCENE-8807
Project: Lucene - Core
Issue Type: Task
Components: general/build
Affects Versions: 8.1
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: master (9.0), 8.2, 8.1.1
At least for Lucene this is not a security issue, because we have checksums for
all downloaded JAR dependencies, but ASF asked all projects to ensure that
download URLs for dependencies are using HTTPS:
{quote}
[...] Projects like Lucene do checksum whitelists of
all their build dependencies, and you may wish to consider that as a
protection against threats beyond just MITM [...]
{quote}
This patch fixes the URLs for most files referenced in {{*build.xml}} and
{{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use HTTP
only, but that's uncritical and I added a TODO. Some were broken already.
I removed the "uk.maven.org" workarounds for Maven, as this does not work with
HTTPS. By keeping those inside, we break the whole chain of trust, as any
non-working HTTPS would fallback to the insecure uk.maven.org Maven mirror.
As the great chinese firewall is changing all the time, we should just wait for
somebody complaining.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843567#comment-16843567 ] Uwe Schindler commented on SOLR-13452: -- FYI: The very late addition of the servlet-api.txt signatures file to the task config does not hurt input/output change detection. As the signatures file is part of the build plugin's classpath (it's loaded with getResource), once the signatures file changes, the forbiddenApis task gets reexecuted anyways, because it's classpath changed. So adding it shortly before task execution is fine, as you can see it like a internal implementation detail of the plugin. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843565#comment-16843565 ] Uwe Schindler commented on SOLR-13452: -- I fixed the forbiddenapis and servlet-api checks: We do not add the servlet-api.txt signatures to the config until shortly before the task runs (using forbiddenTask.doFirst). At this time the fll dependencies are resolved and we check if the forbiddenapis classpath contains the servlet-api.jar file and add the signatures. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843560#comment-16843560 ] Uwe Schindler commented on SOLR-13452: -- Hi Mark, I reworked the forbidden apis stuff to use more readable regexps and I added the missing system-out and commons-io checks. As a workaround I changed the forbiddenapis-config for solr to allow missing signatures, but I will rework solr in a moment, so it works correct with compile-only (otherwise Dawid Weiss will complain...) > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843541#comment-16843541 ] Uwe Schindler commented on SOLR-13452: -- Hi Mark, I will commit soon some refactoring of forbiddenapis. It looks you copied the plugin code mostly from Elasticsearch - but you missed to copy the comment about the "+=" stuff. Actually the configuration is much easier if you but all signatures into each task and not in the superclock "forbiddenApis" (which is an extension function, so it can't easily inherit - one of the horrible details of Gradle). As the signatures differ anyways and we iterate over all tasks, it's better to define them all in the task. Then you can easily add sigantures. I also added the exclusion for the hadoop test classes (in solr/core/build.gradle). About the servlet-api: The problem is the following: As it's a compileOnly dependency, it's not exported by the project. So subprojects need to redefine the compileOnly dependency, if they actually use the classes. As the servlet API is provided by the servlet container at runtime, in reality it should be compileOnly, so you are right and every module that uses the classes has to use compileOnly. The problem in forbiddenApis is that the signatures need to be parsed and this does not work if the classes are not in compile classpath... Therere are 2 ways to solve this: - tell fobidden to ignore unknown sigantures files (I think Lucene's Maven build does this) - only add servlet-api.txt, if the servlet-api is on the classpath. I added some "idea" - which does not yet work - to the code (commented out). It worked partially last thursday, but you changed the code so I was not able to followup. The forbidden code has other problems: - system out checking is still missing - commons-io checks are also missing. I will add them with the correct version number like in Ant's build in the same way like I plan to do the servlet-api detection (look into dependencies / classpath and use correct version) Please don't touch forbidden yet, I'd like to fix this, but it was a changing target... Uwe > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))
[
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841123#comment-16841123
]
Uwe Schindler commented on LUCENE-8041:
---
I have a maybe better suggestion instead of:
- Build a TreeMap like before and name it sortedField()
- Then rebuild it as LinkedHashMap
The problem here is that we have to build a possibly huge map, just to copy it
to a LinkedHashMap, and hotspot can't easily optimize away the creation on
heap. The result is fine (as said before): The LinkedHashMap needs a bit more
heap space than a plain HashMap, but should be of almost identical size to a
TreeMap (which uses a lot of small inner object instances).
My suggestion would be: You just iterate over the fields, do some
transformations and then finally add them to a TreeMap. Rewrite that to use
Java Streams - it may not work for all cases (especially if the iteration has
I/O involved and the order is important), but e.g. for direct fields it may
work (possibly the IOException needs to be wrapped):
{code:java}
public DirectFields(SegmentReadState state, Fields fields, int
minSkipCount, int lowFreqCutoff) throws IOException {
this.fields = StreamSupport.stream(fields.spliterator(), false)
.sorted() // <== that's the trick
.collect(Collectors.toMap(Function.identity(), field -> new
DirectField(state, field, fields.terms(field), minSkipCount, lowFreqCutoff),
(u,v) -> throw new IllegalArgumentException("Duplicate field name"),
LinkedHashMap::new));
}
{code}
This is totally untested, just as an idea! The merge function there is just
stupid, but it's never called as there should be no duplicate keys. This
actually is a bit more strict, if Field is wrongly implemented and returns the
same field name multiple times in its iterator.
> All Fields.terms(fld) impls should be O(1) not O(log(N))
>
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041-LinkedHashMap.patch, LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds. The O(log(N))
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time,
> if I recall. There are many Field implementations that are impacted... in
> part because Fields is the base class of FieldsProducer.
> As an aside, I hope Fields to go away some day; FieldsProducer should be
> TermsProducer and not have an iterator of fields. If DocValuesProducer
> doesn't have this then why should the terms index part of our API have it?
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap
> in many cases if we can assume when we initialize these internal maps that we
> consume them in sorted order to begin with.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840817#comment-16840817
]
Uwe Schindler edited comment on SOLR-13452 at 5/15/19 10:23 PM:
Hi Mark,
I am working on forbidden-apis but there are few additional problems:
(1) First you added an {{include 'build/src'}} in settings.gradle, although
this is not needed. The result of this is that the buildSrc dir is treated as a
separate subproject, so all the configurations are applied to it, too. This
should not be done. I removed it, project still compiles. If you keep the
include, you break the build plugin because it uses itsself to build itsself.
This fails e.g., forbiddenapis. On the other hand, it might be good to run
"rat" on it. But this should be configured in buildSrc directly.
Another option is to give the build source a separate name and exclude it from
the top-level config inside "subprojects" config. This is how Elasticsearch
does it.
(2) There is a problem with the "compileOnly" dependency in solr-core. As it's
compile only its also not exported to projects relying on it. As forbiddenapis
hardcodes it as a signatures file, it wont work. You already excluded solrj,
but it also affect other Solr modules that does not have it. IMHO, I'd change
the configuration to only exclude servlet-api.txt sgnatures if the servlet-api
compileOnly dependency is there.
(3) commons-io is missing. We need some trick to get the version number, but
that's also easy: (like in 2, ask the configuration for the version).
(4) System.out checking is also missing
I fixed (1) locally and working on (2). Once this works, I will look into the
test excldudes for the forked Hadoop test classes. That should be easy (just
change the forbiddenApisTest task in the Solr Core module and exclude
directories).
was (Author: thetaphi):
Hi Mark,
I am working on forbidden-apis but there are 2 additional problems:
(1) First you added an {{include 'build/src'}} in settings.gradle, although
this is not needed. The result of this is that the buildSrc dir is treated as a
separate subproject, so all the configurations are applied to it, too. This
should not be done. I removed it, project still compiles. If you keep the
include, you break the build plugin because it uses itsself to build itsself.
This fails e.g., forbiddenapis. On the other hand, it might be good to run
"rat" on it. But this should be configured in buildSrc directly.
Another option is to give the build source a separate name and exclude it from
the top-level config inside "subprojects" config. This is how Elasticsearch
does it.
(2) There is a problem with the "compileOnly" dependency in solr-core. As it's
compile only its also not exported to projects relying on it. As forbiddenapis
hardcodes it as a signatures file, it wont work. You already excluded solrj,
but it also affect other Solr modules that does not have it. IMHO, I'd change
the configuration to only exclude servlet-api.txt sgnatures if the servlet-api
compileOnly dependency is there.
(3) commons-io is missing. We need some trick to get the version number, but
that's also easy: (like in 2, ask the configuration for the version).
I fixed (1) locally and working on (2). Once this works, I will look into the
test excldudes for the forked Hadoop test classes. That should be easy (just
change the forbiddenApisTest task in the Solr Core module and exclude
directories).
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
> By default, dependencies are not transitive, but there is a special
> Configuration for adding dependencies on other project internal modules that
> are transitive to their direct external dependencies (their jar libs).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840817#comment-16840817
]
Uwe Schindler commented on SOLR-13452:
--
Hi Mark,
I am working on forbidden-apis but there are 2 additional problems:
(1) First you added an {{include 'build/src'}} in settings.gradle, although
this is not needed. The result of this is that the buildSrc dir is treated as a
separate subproject, so all the configurations are applied to it, too. This
should not be done. I removed it, project still compiles. If you keep the
include, you break the build plugin because it uses itsself to build itsself.
This fails e.g., forbiddenapis. On the other hand, it might be good to run
"rat" on it. But this should be configured in buildSrc directly.
Another option is to give the build source a separate name and exclude it from
the top-level config inside "subprojects" config. This is how Elasticsearch
does it.
(2) There is a problem with the "compileOnly" dependency in solr-core. As it's
compile only its also not exported to projects relying on it. As forbiddenapis
hardcodes it as a signatures file, it wont work. You already excluded solrj,
but it also affect other Solr modules that does not have it. IMHO, I'd change
the configuration to only exclude servlet-api.txt sgnatures if the servlet-api
compileOnly dependency is there.
(3) commons-io is missing. We need some trick to get the version number, but
that's also easy: (like in 2, ask the configuration for the version).
I fixed (1) locally and working on (2). Once this works, I will look into the
test excldudes for the forked Hadoop test classes. That should be easy (just
change the forbiddenApisTest task in the Solr Core module and exclude
directories).
> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Reporter: Mark Miller
>Priority: Major
>
> I took some things from the great work that Dat did in
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a
> little further.
>
> When working with gradle in sub modules directly, I recommend
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version
> configuration and version consistency across modules:
> [https://github.com/palantir/gradle-consistent-versions]
> By default, dependencies are not transitive, but there is a special
> Configuration for adding dependencies on other project internal modules that
> are transitive to their direct external dependencies (their jar libs).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840546#comment-16840546 ] Uwe Schindler commented on SOLR-13452: -- One small thing: While playing around, it was hard to me to find all custom defined tasks, as none of them has a description. "gradle tasks" only shows those which have a description. So we should add a short statement for stuff like "regenerate". > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840540#comment-16840540 ] Uwe Schindler commented on SOLR-13452: -- [~markrmil...@gmail.com]: I fixed the working copy check (there was a copy-paste error). What's the exact issue with forbidden-apis? The lucene BuildPlugin is not yet applied on all subprojects, with comment "forbidden" is not working. I temporary enabled it, it just failed because the BuildPlugin itsself uses java.io.File - hihi. IMHO, the build plugin should also contain the JFlex task, currently its applied on top-level. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840505#comment-16840505 ] Uwe Schindler commented on SOLR-13452: -- I'd like to stay with Groovy, too. The main reason why most custom tasks in our Ant build were written in Groovy was also done with "Gradle" in mind. [~mgrigorov]: most of the custom code added here (tasks like source code checker, regenerate of unicode data, and - not yet included here - in Lucene 8.x the MR-JAR creation with classfile patching) was copy-pasted from Ants build and just wrapped with a "gradle task" wrapper. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839434#comment-16839434 ] Uwe Schindler commented on SOLR-13452: -- Hi Mark, branch looks great as a start! Impressive! I will look through it tomorrow, today is a bit busy. Thanks Dawid to be the encoding policeman. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > https://github.com/apache/lucene-solr/tree/jira/gradle and took the ball a > little further. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832463#comment-16832463
]
Uwe Schindler commented on LUCENE-8778:
---
Comments are now there. I fogot to click on "Start Review" (the mobile phone
screens are too small to see everything!).
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: Screenshot from 2019-04-26 02-17-48.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8789) Use JGoodies' look for Luke on Windows platform
[
https://issues.apache.org/jira/browse/LUCENE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832445#comment-16832445
]
Uwe Schindler edited comment on LUCENE-8789 at 5/3/19 11:54 AM:
I see no problem on Java 11. Some minor glitches (font sizes), but thats more a
general Windows problem I think. So no action needed on master / Lucene 9.
On Java 8, the HiDPI displays looks strange with the custom plugin. Font size
is correct, but window size is too small. In addition on the first "open" index
screen the buttons on border are half out of window. The choice list for
directory implementation collapsed vertically to a single line.
Actually the default skin is "small" - but works on Java 8, so actually I wold
not use a custom skin at all. I have a 150% display, so its not too worse,
maybe different for 200% users.
But for all Windows 10 users there is an easy workaround. The problem is that
Java 8 itsself declares as "HiDPI compatible", but actually it isnt. So Windows
won't automatically zoom the pixel sizes and images. To fix this we may need to
add some info to the system requirements section. Right click on "java.exe"
(for "ant run") or "javaw.exe" (for batch file) and choose "HiDPI settings" and
the enable "System (Advanced)" as compatibility mode. The Windows zooms and all
is fine (looks a bit blurry - as usual):
!screenshot-1.png|width=626,height=434!
IMHO: You should change the BATCH file to use java.exe instead of javaw.exe, a
console window is opened anyways, but with javaw.exe you don't get any console
output when something wents wrong.
was (Author: thetaphi):
I see no problem on Java 11. Some minor glitches (font sizes), but thats more a
general Windows problem I think. So no action needed on master / Lucene 9.
On Java 8, the HiDPI displays looks strange with the custom plugin. Font size
is correct, but window size is too small. In addition on the first "open" index
screen the buttons on border are half out of window. The choice list for
directory implementation collapsed vertically to a single line.
Actually the default skin is "small" - but works on Java 8, so actually I wold
not use a custom skin at all. I have a 150% display, so its not too worse,
maybe different for 200% users.
But for all Windows 10 users there is an easy workaround. The problem is that
Java 8 itsself declares as "HiDPI compatible", but actually it isnt. So Windows
won't automatically zoom the pixel sizes and images. To fix this we may need to
add some info to the system requirements section. Right click on "java.exe"
(for "ant run") or "javaw.exe" (for batch file) and choose "HiDPI settings" and
the enable "System (Advanced)" as compatibility mode. The Windows zooms and all
is fine (looks a bit blurry - as usual):
!screenshot-1.png!
IMHO: You should change the BATCH file to use java.exe instead of javaw.exe, a
console window is opened anyways, but with javaw.exe you don't get any console
output when something wents wrong.
> Use JGoodies' look for Luke on Windows platform
>
>
> Key: LUCENE-8789
> URL: https://issues.apache.org/jira/browse/LUCENE-8789
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-8789.patch, Luke_ Lucene Toolbox Project - v9.0.0
> 2019_05_02 11_45_14.png, Luke_ Lucene Toolbox Project - v9.0.0 2019_05_02
> 11_53_37.png, sc_luke_java8.png, screenshot-1.png
>
>
> JGoodies Looks ([http://www.jgoodies.com/freeware/libraries/looks/]) is a
> Swing look library for Windows platform.
> The main advantage of the library is (quoted from their home page):
> {quote}Our Windows look focuses on a precise emulation on Windows XP,
> Vista, 7, 8, 8.1, and now Windows 10 in the following areas: menus, icons,
> colors, borders, fonts, font sizes, insets, and widget dimensions. It honors
> the screen resolution (low vs. high dpi) to adjust sizes, insets, and widget
> dimensions.
> {quote}
> The library works fine on Java11, relatively light weight (400KB), has no
> other external dependencies, and distributed under 2-Clause BSD License (see:
> [http://www.jgoodies.com/downloads/libraries/]).
>
> Actually, I forgot to include this when migrating Luke from the GitHub repo
> to Lucene project... :)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8789) Use JGoodies' look for Luke on Windows platform
[
https://issues.apache.org/jira/browse/LUCENE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16832445#comment-16832445
]
Uwe Schindler commented on LUCENE-8789:
---
I see no problem on Java 11. Some minor glitches (font sizes), but thats more a
general Windows problem I think. So no action needed on master / Lucene 9.
On Java 8, the HiDPI displays looks strange with the custom plugin. Font size
is correct, but window size is too small. In addition on the first "open" index
screen the buttons on border are half out of window. The choice list for
directory implementation collapsed vertically to a single line.
Actually the default skin is "small" - but works on Java 8, so actually I wold
not use a custom skin at all. I have a 150% display, so its not too worse,
maybe different for 200% users.
But for all Windows 10 users there is an easy workaround. The problem is that
Java 8 itsself declares as "HiDPI compatible", but actually it isnt. So Windows
won't automatically zoom the pixel sizes and images. To fix this we may need to
add some info to the system requirements section. Right click on "java.exe"
(for "ant run") or "javaw.exe" (for batch file) and choose "HiDPI settings" and
the enable "System (Advanced)" as compatibility mode. The Windows zooms and all
is fine (looks a bit blurry - as usual):
!screenshot-1.png!
IMHO: You should change the BATCH file to use java.exe instead of javaw.exe, a
console window is opened anyways, but with javaw.exe you don't get any console
output when something wents wrong.
> Use JGoodies' look for Luke on Windows platform
>
>
> Key: LUCENE-8789
> URL: https://issues.apache.org/jira/browse/LUCENE-8789
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-8789.patch, Luke_ Lucene Toolbox Project - v9.0.0
> 2019_05_02 11_45_14.png, Luke_ Lucene Toolbox Project - v9.0.0 2019_05_02
> 11_53_37.png, sc_luke_java8.png, screenshot-1.png
>
>
> JGoodies Looks ([http://www.jgoodies.com/freeware/libraries/looks/]) is a
> Swing look library for Windows platform.
> The main advantage of the library is (quoted from their home page):
> {quote}Our Windows look focuses on a precise emulation on Windows XP,
> Vista, 7, 8, 8.1, and now Windows 10 in the following areas: menus, icons,
> colors, borders, fonts, font sizes, insets, and widget dimensions. It honors
> the screen resolution (low vs. high dpi) to adjust sizes, insets, and widget
> dimensions.
> {quote}
> The library works fine on Java11, relatively light weight (400KB), has no
> other external dependencies, and distributed under 2-Clause BSD License (see:
> [http://www.jgoodies.com/downloads/libraries/]).
>
> Actually, I forgot to include this when migrating Luke from the GitHub repo
> to Lucene project... :)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
