[jira] [Commented] (LUCENE-9548) Publish master (9.x) snapshots to https://repository.apache.org
[ https://issues.apache.org/jira/browse/LUCENE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206673#comment-17206673 ] Uwe Schindler commented on LUCENE-9548: --- Hi Dawid, I don't see any commit that contains this information. I was grepping through te whole repository. > Publish master (9.x) snapshots to https://repository.apache.org > --- > > Key: LUCENE-9548 > URL: https://issues.apache.org/jira/browse/LUCENE-9548 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > We should start publishing snapshot JARs to Apache repositories. I'm not sure > how to set it all up with gradle but maybe there are other Apache projects > that use gradle and we could peek at their config? Mostly it's about signing > artifacts (how to pass credentials for signing) and setting up Nexus > deployment repository. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9500) Did we hit a DEFLATE bug?
[
https://issues.apache.org/jira/browse/LUCENE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206678#comment-17206678
]
Uwe Schindler commented on LUCENE-9500:
---
The bug is fixed in JDK 16 build 18:
{noformat}
$ gradlew :lucene:core:test -Ptests.verbose=true --tests
"TestLucene87StoredFieldsFormatHighCompression" | grep buggy
2> JDK is buggy (JDK-8252739): false
{noformat}
> Did we hit a DEFLATE bug?
> -
>
> Key: LUCENE-9500
> URL: https://issues.apache.org/jira/browse/LUCENE-9500
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Affects Versions: 8.x, master (9.0), 8.7
>Reporter: Adrien Grand
>Assignee: Uwe Schindler
>Priority: Critical
> Labels: Java13, Java14, Java15, java11, jdk11, jdk13, jdk14,
> jdk15
> Fix For: 8.x, master (9.0), 8.7
>
> Attachments: PresetDictTest.java, test_data.txt
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> I've been digging
> [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/]
> all day and managed to isolate a simple reproduction that shows the problem.
> I've been starring at it all day and can't find what we are doing wrong,
> which makes me wonder whether we're calling DEFLATE the wrong way or whether
> we hit a DEFLATE bug. I've looked at it so much that I may be missing the
> most obvious stuff.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] rmuir commented on pull request #1940: LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries
rmuir commented on pull request #1940: URL: https://github.com/apache/lucene-solr/pull/1940#issuecomment-703102285 Thanks for the explanation. For the first use-case, since its an approximation, why use circles instead of n-gons to approximate the circles? Then its just a simple multipolygon and should be fast? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-9557:
Attachment: LUCENE-9557.patch
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
Robert Muir created LUCENE-9557:
---
Summary: gradle regeneration of HTMLCharacterEntities.jflex should
not use python2
Key: LUCENE-9557
URL: https://issues.apache.org/jira/browse/LUCENE-9557
Project: Lucene - Core
Issue Type: Improvement
Reporter: Robert Muir
Attachments: LUCENE-9557.patch
I thought we had cleaned out the python2, but we got one straggler left.
Currently this is set to run with python2, but it should be using python3.
Python3 will generate the exact same sources that are present in master today.
But if you run it with python2 (as currently configured) it generates a
slightly different grammar:
{noformat}
---
a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
+++
b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
@@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" | "Agrave"
| "Alpha"
| "times" | "trade" | "uArr" | "uacute" | "uarr" | "ucirc"
| "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
| "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
-| "zwj" | "zwnj" )
+('| "zwj" | "zwnj"', ')')
{noformat}
This then cascades and causes HTMLStripCharFilter.java to be regenerated
differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206696#comment-17206696
]
Robert Muir commented on LUCENE-9557:
-
trivial patch: just specify python3 and it regenerates the current sources.
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14910) Use in-line tags for logger declarations in Gradle ValidateLogCalls that are non-standard, change //logok to //nowarn
[ https://issues.apache.org/jira/browse/SOLR-14910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206700#comment-17206700 ] ASF subversion and git services commented on SOLR-14910: Commit f6c4f8a755603c3049e48eaf9511041252f2dbad in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f6c4f8a ] SOLR-14910: Use in-line tags for logger declarations in Gradle ValidateLogCalls that are non-standard, change //logok to //nowarn > Use in-line tags for logger declarations in Gradle ValidateLogCalls that are > non-standard, change //logok to //nowarn > - > > Key: SOLR-14910 > URL: https://issues.apache.org/jira/browse/SOLR-14910 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson closed pull request #1942: SOLR-14910: Use in-line tags for logger declarations in Gradle ValidateLogCalls that are non-standard, change //logok to //nowarn
ErickErickson closed pull request #1942: URL: https://github.com/apache/lucene-solr/pull/1942 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on pull request #1942: SOLR-14910: Use in-line tags for logger declarations in Gradle ValidateLogCalls that are non-standard, change //logok to //nowarn
ErickErickson commented on pull request #1942: URL: https://github.com/apache/lucene-solr/pull/1942#issuecomment-703106751 Pushed to master This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14910) Use in-line tags for logger declarations in Gradle ValidateLogCalls that are non-standard, change //logok to //nowarn
[ https://issues.apache.org/jira/browse/SOLR-14910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206702#comment-17206702 ] ASF subversion and git services commented on SOLR-14910: Commit d253b307e31a04d28e4bc6f3168167982a38f68f in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d253b30 ] SOLR-14910: Use in-line tags for logger declarations in Gradle ValidateLogCalls that are non-standard, change //logok to //nowarn > Use in-line tags for logger declarations in Gradle ValidateLogCalls that are > non-standard, change //logok to //nowarn > - > > Key: SOLR-14910 > URL: https://issues.apache.org/jira/browse/SOLR-14910 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206740#comment-17206740
]
Uwe Schindler commented on LUCENE-9557:
---
Maybe check if there's some definition of external tool still there, if yes we
can remove it, too. But I think Dawid made the sysprop for python2 dynamic.
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206746#comment-17206746
]
Uwe Schindler commented on LUCENE-9557:
---
I think the reason for the difference was early stages of Gradle. There was
only "python" int ants build, but on most systems this defaults to python 2.7
(Ubuntu, Solaris). Maybe mac is different. I strongly prefer to say "python3"
with version number. Maybe add a forbidden source patterns rule: disallow
python without digit. 😜
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206749#comment-17206749
]
Robert Muir commented on LUCENE-9557:
-
This is the only match for 'python2' in the whole source tree. Like I said, its
clearly wrong, if you run it against master today, you will see that the DFA
changes. with my patch, DFA doesn't change.
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206751#comment-17206751
]
Robert Muir commented on LUCENE-9557:
-
To answer your question though, this is how that "externalTool" works:
{code}
// Allow definiting external tool locations using system props.
externalTool = { name ->
def resolved = propertyOrDefault("${name}.exe", name as String)
logger.info("External tool '${name}' resolved to: ${resolved}")
return resolved
}
{code}
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206753#comment-17206753
]
Uwe Schindler commented on LUCENE-9557:
---
Ok, perfect.
I was not against the patch. I just explained where this came from. Python
without digit depends on platform. And the generator committee maybe not used
Linux.
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206754#comment-17206754
]
Uwe Schindler commented on LUCENE-9557:
---
When reviewing the external tools a while back, I went through all tools and
replaced "python" by "python2" because that's the default on a freshly
installed debian or Ubuntu Linux, or Solaris. Ok? So please forgive me.
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206755#comment-17206755
]
Uwe Schindler commented on LUCENE-9557:
---
And because of this (happens quite often) we should prevent anybody from
writing scripts calling python without version number.
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9558) Clean up package name conflicts for analyzers-icu module
Tomoko Uchida created LUCENE-9558:
-
Summary: Clean up package name conflicts for analyzers-icu module
Key: LUCENE-9558
URL: https://issues.apache.org/jira/browse/LUCENE-9558
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Reporter: Tomoko Uchida
analyzers-icu module shares the package names {{o.a.l.collation}} and
{{o.a.l.collation.tokenattributes}} with analyzers-common; they need to be
renamed.
There could be two solutions:
1. rename "o.a.l.collation" to "o.a.l.a.icu.collation"
2. move classes under "o.a.l.collation" to "o.a.l.a.icu" and classes under
"o.a.l.collation.tokenattributes" to "o.a.l.a.icu.tokenattributes", and delete
"o.a.l.collation" from analyzers-icu
I would prefer option 2. 1. may complicate the package hierarchy and there
already exist {{o.a.l.a.icu.tokenattributes}}. (All classes under
"o.a.l.collation" have prefix "ICU", so I think we don't need to keep
"collation" in the package name, do we?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-9558) Clean up package name conflicts for analyzers-icu module
[
https://issues.apache.org/jira/browse/LUCENE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida reassigned LUCENE-9558:
-
Assignee: Tomoko Uchida
> Clean up package name conflicts for analyzers-icu module
>
>
> Key: LUCENE-9558
> URL: https://issues.apache.org/jira/browse/LUCENE-9558
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> analyzers-icu module shares the package names {{o.a.l.collation}} and
> {{o.a.l.collation.tokenattributes}} with analyzers-common; they need to be
> renamed.
> There could be two solutions:
> 1. rename "o.a.l.collation" to "o.a.l.a.icu.collation"
> 2. move classes under "o.a.l.collation" to "o.a.l.a.icu" and classes under
> "o.a.l.collation.tokenattributes" to "o.a.l.a.icu.tokenattributes", and
> delete "o.a.l.collation" from analyzers-icu
> I would prefer option 2. 1. may complicate the package hierarchy and there
> already exist {{o.a.l.a.icu.tokenattributes}}. (All classes under
> "o.a.l.collation" have prefix "ICU", so I think we don't need to keep
> "collation" in the package name, do we?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9499) Clean up package name conflicts between modules (split packages)
[
https://issues.apache.org/jira/browse/LUCENE-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-9499:
--
Description:
We have lots of package name conflicts (shared package names) between modules
in the source tree. It is not only annoying for devs/users but also indeed bad
practice since Java 9 (according to my understanding), and we already have some
problems with Javadocs due to these splitted packages as some of us would know.
Also split packages make migrating to the Java 9 module system impossible.
This is the placeholder to fix all package name conflicts in Lucene.
See the dev list thread for more background.
[https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
Modules that need to be fixed / cleaned up:
- analyzers-common (LUCENE-9317)
- analyzers-icu (LUCENE-9558)
- backward-codecs (LUCENE-9318)
- sandbox (LUCENE-9319)
- misc
- (test-framework: this can be excluded for the moment)
Also lucene-core will be heavily affected (some classes have to be moved into
{{core}}, or some classes' and methods' in {{core}} visibility have to be
relaxed).
Probably most work would be done in a parallel manner, but conflicts can
happen. If someone want to help out, please open an issue before working and
share your thoughts with me and others.
I set "Fix version" to 9.0 - means once we make a commit on here, this will be
a blocker for release 9.0.0. (I don't think the changes should be delivered
across two major releases; all changes have to be out at once in a major
release.) If there are any objections or concerns, please leave comments. For
now I have no idea about the total volume of changes or technical obstacles
that have to be handled.
was:
We have lots of package name conflicts (shared package names) between modules
in the source tree. It is not only annoying for devs/users but also indeed bad
practice since Java 9 (according to my understanding), and we already have some
problems with Javadocs due to these splitted packages as some of us would know.
Also split packages make migrating to the Java 9 module system impossible.
This is the placeholder to fix all package name conflicts in Lucene.
See the dev list thread for more background.
[https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
Modules that need to be fixed / cleaned up:
- analyzers-common (LUCENE-9317)
- analyzers-icu
- backward-codecs (LUCENE-9318)
- sandbox (LUCENE-9319)
- misc
- (test-framework: this can be excluded for the moment)
Also lucene-core will be heavily affected (some classes have to be moved into
{{core}}, or some classes' and methods' in {{core}} visibility have to be
relaxed).
Probably most work would be done in a parallel manner, but conflicts can
happen. If someone want to help out, please open an issue before working and
share your thoughts with me and others.
I set "Fix version" to 9.0 - means once we make a commit on here, this will be
a blocker for release 9.0.0. (I don't think the changes should be delivered
across two major releases; all changes have to be out at once in a major
release.) If there are any objections or concerns, please leave comments. For
now I have no idea about the total volume of changes or technical obstacles
that have to be handled.
> Clean up package name conflicts between modules (split packages)
>
>
> Key: LUCENE-9499
> URL: https://issues.apache.org/jira/browse/LUCENE-9499
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
>
> We have lots of package name conflicts (shared package names) between modules
> in the source tree. It is not only annoying for devs/users but also indeed
> bad practice since Java 9 (according to my understanding), and we already
> have some problems with Javadocs due to these splitted packages as some of us
> would know. Also split packages make migrating to the Java 9 module system
> impossible.
> This is the placeholder to fix all package name conflicts in Lucene.
> See the dev list thread for more background.
>
> [https://lists.apache.org/thread.html/r6496963e89a5e0615e53206429b6843cc5d3e923a2045cc7b7a1eb03%40%3Cdev.lucene.apache.org%3E]
> Modules that need to be fixed / cleaned up:
> - analyzers-common (LUCENE-9317)
> - analyzers-icu (LUCENE-9558)
> - backward-codecs (LUCENE-9318)
> - sandbox (LUCENE-9319)
> - misc
> - (test-framework: this can be excluded for the moment)
> Also lucene-core will be heavily affected (some classes have to be moved into
> {{core}}
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206783#comment-17206783
]
Robert Muir commented on LUCENE-9557:
-
yeah, that explains how i may have missed it before, something calling
{{python}} which is not good (you have no idea what it may be, on my system it
just happens to be python 3 but on others it is python 2)
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206784#comment-17206784
]
ASF subversion and git services commented on LUCENE-9557:
-
Commit 7eee4fd1026355a3e420bf02a7578eee6826bc97 in lucene-solr's branch
refs/heads/master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7eee4fd ]
LUCENE-9557: regeneration should use python3, not python2
python2 will change the DFA, but using python3 re-generates the sources
as they exist today. plus, we don't want to depend on EOL python2.
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-9557.
-
Fix Version/s: master (9.0)
Resolution: Fixed
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206786#comment-17206786
]
Uwe Schindler commented on LUCENE-9557:
---
Thanks! ❤️👍🏻
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] iverase commented on pull request #1940: LUCENE-9552: Adds a LatLonPoint query that accepts an array of LatLonGeometries
iverase commented on pull request #1940: URL: https://github.com/apache/lucene-solr/pull/1940#issuecomment-703130472 Yes, approximating the circle to a polygon would work. You will have a penalty in performance depending how many points you use for approximating the circle (which is something the user will have to decide). But I am afraid if this solution scales well. The example I gave was the simple case, in general the input can be a path that can contains hundred of line segments. That mean you can end up with hundred of circles that you need to approximate using polygons with potentially thousands of edges. I would expect that at some point it can get very inefficient, even just building the query. I would find a pity not to expose the capability accepting heterogeneous geometries as it is something that is already supported internally. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9558) Clean up package name conflicts for analyzers-icu module
[
https://issues.apache.org/jira/browse/LUCENE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-9558:
--
Description:
analyzers-icu module shares the package names {{o.a.l.collation}} and
{{o.a.l.collation.tokenattributes}} with analyzers-common; they need to be
renamed.
There could be two solutions:
1. rename "o.a.l.collation" to "o.a.l.a.icu.collation"
2. move classes under "o.a.l.collation" to "o.a.l.a.icu" and classes under
"o.a.l.collation.tokenattributes" to "o.a.l.a.icu.tokenattributes", and delete
"o.a.l.collation" from analyzers-icu
I would prefer option 2. 1. may complicate the package hierarchy and there
already exist {{o.a.l.a.icu.tokenattributes}}. (All classes under
"o.a.l.collation" have prefix "ICUCollation", so I think we don't need to keep
"collation" in the package name, do we?)
was:
analyzers-icu module shares the package names {{o.a.l.collation}} and
{{o.a.l.collation.tokenattributes}} with analyzers-common; they need to be
renamed.
There could be two solutions:
1. rename "o.a.l.collation" to "o.a.l.a.icu.collation"
2. move classes under "o.a.l.collation" to "o.a.l.a.icu" and classes under
"o.a.l.collation.tokenattributes" to "o.a.l.a.icu.tokenattributes", and delete
"o.a.l.collation" from analyzers-icu
I would prefer option 2. 1. may complicate the package hierarchy and there
already exist {{o.a.l.a.icu.tokenattributes}}. (All classes under
"o.a.l.collation" have prefix "ICU", so I think we don't need to keep
"collation" in the package name, do we?)
> Clean up package name conflicts for analyzers-icu module
>
>
> Key: LUCENE-9558
> URL: https://issues.apache.org/jira/browse/LUCENE-9558
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> analyzers-icu module shares the package names {{o.a.l.collation}} and
> {{o.a.l.collation.tokenattributes}} with analyzers-common; they need to be
> renamed.
> There could be two solutions:
> 1. rename "o.a.l.collation" to "o.a.l.a.icu.collation"
> 2. move classes under "o.a.l.collation" to "o.a.l.a.icu" and classes under
> "o.a.l.collation.tokenattributes" to "o.a.l.a.icu.tokenattributes", and
> delete "o.a.l.collation" from analyzers-icu
> I would prefer option 2. 1. may complicate the package hierarchy and there
> already exist {{o.a.l.a.icu.tokenattributes}}. (All classes under
> "o.a.l.collation" have prefix "ICUCollation", so I think we don't need to
> keep "collation" in the package name, do we?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9557) gradle regeneration of HTMLCharacterEntities.jflex should not use python2
[
https://issues.apache.org/jira/browse/LUCENE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206813#comment-17206813
]
Erick Erickson commented on LUCENE-9557:
I think this about drove me crazy when I did the initial Gradle work and I
never did track it down, thanks!
> gradle regeneration of HTMLCharacterEntities.jflex should not use python2
> -
>
> Key: LUCENE-9557
> URL: https://issues.apache.org/jira/browse/LUCENE-9557
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-9557.patch
>
>
> I thought we had cleaned out the python2, but we got one straggler left.
> Currently this is set to run with python2, but it should be using python3.
> Python3 will generate the exact same sources that are present in master
> today. But if you run it with python2 (as currently configured) it generates
> a slightly different grammar:
> {noformat}
> ---
> a/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> +++
> b/lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLCharacterEntities.jflex
> @@ -60,7 +60,7 @@ CharacterEntities = ( "AElig" | "Aacute" | "Acirc" |
> "Agrave" | "Alpha"
> | "times" | "trade" | "uArr" | "uacute" | "uarr" |
> "ucirc"
> | "ugrave" | "uml" | "upsih" | "upsilon" | "uuml"
> | "weierp" | "xi" | "yacute" | "yen" | "yuml" | "zeta"
> -| "zwj" | "zwnj" )
> +('| "zwj" | "zwnj"', ')')
> {noformat}
> This then cascades and causes HTMLStripCharFilter.java to be regenerated
> differently too with a different DFA.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-9559:
Attachment: LUCENE-9559.patch
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9559.patch
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
Robert Muir created LUCENE-9559:
---
Summary: fix "gradle eclipse" to build in eclipse again
Key: LUCENE-9559
URL: https://issues.apache.org/jira/browse/LUCENE-9559
Project: Lucene - Core
Issue Type: Improvement
Reporter: Robert Muir
Attachments: LUCENE-9559.patch
The current "gradle eclipse" produces a non-working setup: you have compilation
errors because of some java files in solr's {{test-files}} that don't compile.
eclipse doesn't differentiate between a resource folder and a sources folder,
classpath entries are just "src" and it tries to compile the java files it sees
in there, which fails.
So let's tell it not to compile them so that gradle eclipse works again: I
don't know what crazy stuff solr is doing here, but i want the IDE to work
again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-9559:
Attachment: compilefailure.png
Status: Open (was: Open)
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9559.patch, compilefailure.png
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206818#comment-17206818
]
Robert Muir commented on LUCENE-9559:
-
Attached is a patch, excluding these java files from that test folder. It
removes the error and the workspace builds again.
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9559.patch, compilefailure.png
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9558) Clean up package name conflicts for analyzers-icu module
[
https://issues.apache.org/jira/browse/LUCENE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206822#comment-17206822
]
Robert Muir commented on LUCENE-9558:
-
+1
> Clean up package name conflicts for analyzers-icu module
>
>
> Key: LUCENE-9558
> URL: https://issues.apache.org/jira/browse/LUCENE-9558
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> analyzers-icu module shares the package names {{o.a.l.collation}} and
> {{o.a.l.collation.tokenattributes}} with analyzers-common; they need to be
> renamed.
> There could be two solutions:
> 1. rename "o.a.l.collation" to "o.a.l.a.icu.collation"
> 2. move classes under "o.a.l.collation" to "o.a.l.a.icu" and classes under
> "o.a.l.collation.tokenattributes" to "o.a.l.a.icu.tokenattributes", and
> delete "o.a.l.collation" from analyzers-icu
> I would prefer option 2. 1. may complicate the package hierarchy and there
> already exist {{o.a.l.a.icu.tokenattributes}}. (All classes under
> "o.a.l.collation" have prefix "ICUCollation", so I think we don't need to
> keep "collation" in the package name, do we?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206824#comment-17206824
]
Uwe Schindler commented on LUCENE-9559:
---
Hi,
the bug seems to be caused by accidentally committed JAVA class files in:
{noformat}
$ git log MyTextField.java
commit 01da67c728df1e46ed82fee1a178546c0665b421
Author: noble
Date: Tue Sep 29 15:25:22 2020 +1000
SOLR-14901: TestPackages uses binary precompiled classes to refer to
analysis factory FQCNs
{noformat}
Before applying such a hack to the Eclipse build, I'd strongly recommend to do
the following:
- [~noble.paul]: Please revert adding {{*.java}} files to Solr's
resources/test-files. This confuses IDEs. If they are valid Java classes move
them to test sources. I found no test using them as resources at all.
- if those files are the "source" of the stuff used as JAR files and CLASS
files in the resources folder (which should not have committed at all to
Git!!!), place them in a separate source dir and let Gradle build all the TEST
JARs (e.g., as separate SourceSets - that's quite easy to do with Grdale, I can
elp - I just have no idea how to produce those JAR/CLASS files) and remove the
m from Git!
Nevertheless, as a first step please remove source files from resource folders.
They don't belong there! Please revert the above commit. Thanks.
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9559.patch, compilefailure.png
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14901) TestPackages uses binary precompiled classes to refer to analysis factory FQCNs
[
https://issues.apache.org/jira/browse/SOLR-14901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206826#comment-17206826
]
Uwe Schindler commented on SOLR-14901:
--
Sorry, committing source files to resources folder breaks certain IDEs (like
Eclipse).
Please revert the commit adding the source files or fix them to be in correct
"source" folders.
IMHO, the JAR files as CLASS files should never be committed to Git, that's
against Apache principles. IMHO, we should add a seoarate Gradle Sourceset to
generate them and package them,
See LUCENE-9559 for explanation.
> TestPackages uses binary precompiled classes to refer to analysis factory
> FQCNs
> ---
>
> Key: SOLR-14901
> URL: https://issues.apache.org/jira/browse/SOLR-14901
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Noble Paul
>Priority: Minor
>
> Base analysis factories' package name were renamed in [LUCENE-9317].
> {{o.a.s.pkg.TestPackages}} is failing since it has hard coded their old
> FQCNs, that needs to be fixed.
> See https://github.com/apache/lucene-solr/pull/1836 for details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9548) Publish master (9.x) snapshots to https://repository.apache.org
[
https://issues.apache.org/jira/browse/LUCENE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206827#comment-17206827
]
Dawid Weiss commented on LUCENE-9548:
-
It is part of the pull request, Uwe -
https://github.com/apache/lucene-solr/pull/1929/files
This commit adds these tasks:
https://github.com/apache/lucene-solr/pull/1929/commits/d6380a395aa70e0c95d0066412a9a7a6e0d1
You need to get the PR patch and apply it locally or just get that branch from
my repository:
{code}
git remote add dweiss g...@github.com:dweiss/lucene-solr.git
git fetch dweiss
git checkout LUCENE-9548
{code}
> Publish master (9.x) snapshots to https://repository.apache.org
> ---
>
> Key: LUCENE-9548
> URL: https://issues.apache.org/jira/browse/LUCENE-9548
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We should start publishing snapshot JARs to Apache repositories. I'm not sure
> how to set it all up with gradle but maybe there are other Apache projects
> that use gradle and we could peek at their config? Mostly it's about signing
> artifacts (how to pass credentials for signing) and setting up Nexus
> deployment repository.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler reassigned LUCENE-9559:
-
Assignee: Uwe Schindler
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-9559.patch, compilefailure.png
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206828#comment-17206828
]
Uwe Schindler commented on LUCENE-9559:
---
I will take care of cleaning that up, if we dont find a solution. But I request
a revert.
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-9559.patch, compilefailure.png
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9548) Publish master (9.x) snapshots to https://repository.apache.org
[ https://issues.apache.org/jira/browse/LUCENE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206829#comment-17206829 ] Dawid Weiss commented on LUCENE-9548: - Also, I would love to hide the convention tasks somehow (they're not really relevant and have longish names) but I couldn't do it - for some reason the obvious hacks (setting group to null) doesn't work [1]. [1] https://discuss.gradle.org/t/hide-convention-publishing-tasks-from-help/37775 > Publish master (9.x) snapshots to https://repository.apache.org > --- > > Key: LUCENE-9548 > URL: https://issues.apache.org/jira/browse/LUCENE-9548 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > We should start publishing snapshot JARs to Apache repositories. I'm not sure > how to set it all up with gradle but maybe there are other Apache projects > that use gradle and we could peek at their config? Mostly it's about signing > artifacts (how to pass credentials for signing) and setting up Nexus > deployment repository. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14901) TestPackages uses binary precompiled classes to refer to analysis factory FQCNs
[
https://issues.apache.org/jira/browse/SOLR-14901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206832#comment-17206832
]
Dawid Weiss commented on SOLR-14901:
Or just look up their .class files at runtime and copy/ sign them where
appropriate?
> TestPackages uses binary precompiled classes to refer to analysis factory
> FQCNs
> ---
>
> Key: SOLR-14901
> URL: https://issues.apache.org/jira/browse/SOLR-14901
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Noble Paul
>Priority: Minor
>
> Base analysis factories' package name were renamed in [LUCENE-9317].
> {{o.a.s.pkg.TestPackages}} is failing since it has hard coded their old
> FQCNs, that needs to be fixed.
> See https://github.com/apache/lucene-solr/pull/1836 for details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-9559:
--
Component/s: general/build
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-9559.patch, compilefailure.png
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-9559:
--
Affects Version/s: master (9.0)
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-9559.patch, compilefailure.png
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram commented on a change in pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.
sigram commented on a change in pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#discussion_r499169806
##
File path: solr/core/src/java/org/apache/solr/cluster/events/ClusterEvent.java
##
@@ -0,0 +1,57 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.cluster.events;
+
+import org.apache.solr.common.MapWriter;
+
+import java.io.IOException;
+import java.time.Instant;
+
+/**
+ * Cluster-level event.
+ */
+public interface ClusterEvent extends MapWriter {
Review comment:
Makes sense, I'll remove it
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] sigram commented on a change in pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.
sigram commented on a change in pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#discussion_r499170285
##
File path:
solr/core/src/java/org/apache/solr/cluster/events/impl/CollectionsRepairEventListener.java
##
@@ -0,0 +1,185 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.cluster.events.impl;
+
+import java.io.IOException;
+import java.lang.invoke.MethodHandles;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.client.solrj.cloud.SolrCloudManager;
+import org.apache.solr.client.solrj.request.CollectionAdminRequest;
+import org.apache.solr.cloud.api.collections.Assign;
+import org.apache.solr.cluster.events.ClusterEvent;
+import org.apache.solr.cluster.events.ClusterEventListener;
+import org.apache.solr.cluster.events.NodesDownEvent;
+import org.apache.solr.cluster.events.ReplicasDownEvent;
+import org.apache.solr.common.cloud.ClusterState;
+import org.apache.solr.common.cloud.Replica;
+import org.apache.solr.common.cloud.ReplicaPosition;
+import org.apache.solr.core.CoreContainer;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * This is an illustration how to re-implement the combination of 8x
+ * NodeLostTrigger and AutoAddReplicasPlanAction to maintain the collection's
replication factor.
+ * NOTE: there's no support for 'waitFor' yet.
+ * NOTE 2: this functionality would be probably more reliable when executed
also as a
+ * periodically scheduled check - both as a reactive (listener) and proactive
(scheduled) measure.
+ */
+public class CollectionsRepairEventListener implements ClusterEventListener {
Review comment:
Not yet - there's a unit test. I implemented this class to illustrate
that the events API is sufficient to bring back the "autoAddReplicas"
functionality that we removed in master.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1937: LUCENE-9541 ConjunctionDISI sub-iterators check
jpountz commented on a change in pull request #1937:
URL: https://github.com/apache/lucene-solr/pull/1937#discussion_r499180389
##
File path:
lucene/core/src/test/org/apache/lucene/search/TestConjunctionDISI.java
##
@@ -391,4 +391,20 @@ public void testCollapseSubConjunctionDISIs() throws
IOException {
public void testCollapseSubConjunctionScorers() throws IOException {
testCollapseSubConjunctions(true);
}
+
+ public void testIllegalAdvancementOfSubIteratorsTripsAssertion() throws
IOException {
+int maxDoc = 100;
Review comment:
I think we need to call something like `assumeTrue(assertsAreEnabled)`
since this test requires assertions to be enabled to succeed.
##
File path:
lucene/core/src/test/org/apache/lucene/search/TestConjunctionDISI.java
##
@@ -391,4 +391,20 @@ public void testCollapseSubConjunctionDISIs() throws
IOException {
public void testCollapseSubConjunctionScorers() throws IOException {
testCollapseSubConjunctions(true);
}
+
+ public void testIllegalAdvancementOfSubIteratorsTripsAssertion() throws
IOException {
+int maxDoc = 100;
+final int numIterators = TestUtil.nextInt(random(), 2, 5);
+FixedBitSet set = randomSet(maxDoc);
+
+DocIdSetIterator[] iterators = new DocIdSetIterator[numIterators];
+for (int i = 0; i < iterators.length; ++i) {
+ iterators[i] = new BitDocIdSet(set).iterator();
+}
+final DocIdSetIterator conjunction =
ConjunctionDISI.intersectIterators(Arrays.asList(iterators));
+int idx = TestUtil.nextInt(random() , 0, iterators.length-1);
+iterators[idx].nextDoc(); // illegally advancing one of the sub-iterators
outside of the conjunction iterator
+AssertionError ex = expectThrows(AssertionError.class, () ->
conjunction.nextDoc());
+assertEquals(ex.getMessage(), "Sub-iterators of ConjunctionDISI are not
the same document!");
Review comment:
can you revert the two arguments to assertEquals? it expects the
expected value first and the actual value second. While swapping arguments
doesn't cause major issues, it creates confusing error messages when the
assertion fails.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1912: LUCENE-9535: Try to do larger flushes.
jpountz commented on a change in pull request #1912:
URL: https://github.com/apache/lucene-solr/pull/1912#discussion_r499180612
##
File path:
lucene/core/src/java/org/apache/lucene/index/ApproximatePriorityQueue.java
##
@@ -0,0 +1,136 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.index;
+
+import java.util.ArrayList;
+import java.util.List;
+import java.util.ListIterator;
+import java.util.function.Predicate;
+
+/**
+ * An approximate priority queue, which attempts to poll items by decreasing
+ * log of the weight, though exact ordering is not guaranteed.
+ * This class doesn't support null elements.
+ */
+final class ApproximatePriorityQueue {
+
+ // Indexes between 0 and 63 are sparely populated, and indexes that are
+ // greater than or equal to 64 are densely populated
+ // Items closed to the beginning of this list are more likely to have a
+ // higher weight.
+ private final List slots = new ArrayList<>(Long.SIZE);
+
+ // A bitset where ones indicate that the corresponding index in `slots` is
taken.
+ private long usedSlots = 0L;
+
+ ApproximatePriorityQueue() {
+for (int i = 0; i < Long.SIZE; ++i) {
+ slots.add(null);
+}
+ }
+
+ /**
+ * Add an entry to this queue that has the provided weight.
+ */
+ void add(T entry, long weight) {
+if (entry == null) {
+ throw new NullPointerException();
+}
+
+final int expectedSlot = Long.numberOfLeadingZeros(weight);
+
+// If the slot is already taken, we take the next one that is free.
+final long freeSlots = ~usedSlots;
+int destinationSlot = expectedSlot + Long.numberOfTrailingZeros(freeSlots
>>> expectedSlot);
Review comment:
you understood it correctly, I'll add the suggested comment and assert
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1912: LUCENE-9535: Try to do larger flushes.
jpountz commented on a change in pull request #1912:
URL: https://github.com/apache/lucene-solr/pull/1912#discussion_r499180984
##
File path:
lucene/core/src/java/org/apache/lucene/index/ApproximatePriorityQueue.java
##
@@ -0,0 +1,136 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.index;
+
+import java.util.ArrayList;
+import java.util.List;
+import java.util.ListIterator;
+import java.util.function.Predicate;
+
+/**
+ * An approximate priority queue, which attempts to poll items by decreasing
+ * log of the weight, though exact ordering is not guaranteed.
+ * This class doesn't support null elements.
+ */
+final class ApproximatePriorityQueue {
+
+ // Indexes between 0 and 63 are sparely populated, and indexes that are
+ // greater than or equal to 64 are densely populated
+ // Items closed to the beginning of this list are more likely to have a
+ // higher weight.
+ private final List slots = new ArrayList<>(Long.SIZE);
+
+ // A bitset where ones indicate that the corresponding index in `slots` is
taken.
+ private long usedSlots = 0L;
+
+ ApproximatePriorityQueue() {
+for (int i = 0; i < Long.SIZE; ++i) {
+ slots.add(null);
+}
+ }
+
+ /**
+ * Add an entry to this queue that has the provided weight.
+ */
+ void add(T entry, long weight) {
+if (entry == null) {
+ throw new NullPointerException();
+}
+
+final int expectedSlot = Long.numberOfLeadingZeros(weight);
+
+// If the slot is already taken, we take the next one that is free.
+final long freeSlots = ~usedSlots;
+int destinationSlot = expectedSlot + Long.numberOfTrailingZeros(freeSlots
>>> expectedSlot);
+if (destinationSlot < Long.SIZE) {
+ usedSlots |= 1L << destinationSlot;
+ slots.set(destinationSlot, entry);
+} else {
+ slots.add(entry);
Review comment:
You're right that this code is unlikely to be exercised unless there are
many indexing threads.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on pull request #1912: LUCENE-9535: Try to do larger flushes.
jpountz commented on pull request #1912: URL: https://github.com/apache/lucene-solr/pull/1912#issuecomment-703163915 > I am a bit worried about perf impact of this new "best effort" priority queue. Yeah I looked into it because I was worried of the performance impact of a proper priority queue which needs to do non-negligible work on every push/poll to keep the queue ordered. But it's not clear to me how much more costly it is compared to the current approach. I was planning on running another benchmark with a lighter indexing chain to better see the impact of this change, e.g. with doc-value fields only, so that the amount of work that is performed between the time when the DWPT pool is polled and the time when the DWPT is added back to the queue is not much heavier than the action of polling from / pushing to the queue. > I'm curious to see impact on nightly indexing. So am I. :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14910) Use in-line tags for logger declarations in Gradle ValidateLogCalls that are non-standard, change //logok to //nowarn
[ https://issues.apache.org/jira/browse/SOLR-14910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14910. --- Fix Version/s: 8.7 Resolution: Fixed > Use in-line tags for logger declarations in Gradle ValidateLogCalls that are > non-standard, change //logok to //nowarn > - > > Key: SOLR-14910 > URL: https://issues.apache.org/jira/browse/SOLR-14910 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14861) CoreContainer shutdown needs to be aware of other ongoing operations and wait until they're complete
[ https://issues.apache.org/jira/browse/SOLR-14861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206859#comment-17206859 ] Erick Erickson commented on SOLR-14861: --- Some notes from the dev list: Erick Erickson: Generically, we need a mechanism that, when we shut Solr down we 1> stop any new requests from being processed. IMO they should be rejected immediately 2> wait for all in-flight operations to complete. This could get tricky if one of the operations is, say, optimize. 3> then shut down. Then perhaps rework the test harness to use that mechanism rather than call CoreContainer.shutdown() directly. That said, I don’t have a clue how to make that happen. David Smiley's reply: Definitely makes sense to me -- those 3 phases of shutdown. That is what I think CoreContainer.shutdown() should itself do. Flag that shutdown has been requested, then wait sufficiently aided by a Semaphore perhaps (note all requests would need to take/release this), then actually do shutdown. > CoreContainer shutdown needs to be aware of other ongoing operations and wait > until they're complete > > > Key: SOLR-14861 > URL: https://issues.apache.org/jira/browse/SOLR-14861 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-14861.patch > > > Noble and I are trying to get to the bottom of the TestBulkSchemaConcurrent > failures and found what looks like a glaring gap in how > CoreContainer.shutdown operates. I don't know the impact on production since > we're shutting down anyway, but I think this is responsible for the errors in > TestBulkSchemaConcurrent and likely behind others, especially any other test > that fails intermittently that involves core reloads, including and > especially any tests that exercise managed schema. > We have clear evidence of this sequence: > 1> some CoreContainer.reloads come in and get _partway_ through, in > particular past the test at the top where CoreContainer.reload() throws an > AlreadyClosed exception if (isShutdown). > 2> Some CoreContainer.shutdown() threads get some processing time before the > reloads in <1> are finished. > 3> the threads in <1> pick back up and go wonky. I suspect that there are a > number of different things that could be going wrong here depending on how > far through CoreContainer.shutdown() gets that pop out in different ways. > Since it's my shift (Noble has to sleep sometime), I put some crude locking > in just to test the idea; incrementing an AtomicInteger on entry to > CoreContainer.reload then decrementing it at the end, and spinning in > CoreContainer.shutdown() until the AtomicInteger was back to zero. With that > in place, 100 runs and no errors whereas before I could never get even 10 > runs to finish without an error. This is not a proper fix at all, and the way > it's currently running there are still possible race conditions, just much > smaller windows. And I suspect it risks spinning forever. But it's enough to > make me believe I finally understand what's happening. > I also suspect that reload is more sensitive than most operations on a core > due to the fact that it runs for a long time, but I assume other operations > have the same potential. Shouldn't CoreContainer.shutDown() wait until no > other operations are in flight? > On a quick scan of CoreContainer, there are actually few places where we even > check for isShutdown, I suspect the places we do are ad-hoc that we've found > by trial-and-error when tests fail. We need a design rather than hit-or-miss > hacking. > I think that isShutdown should be replaced with something more robust. What > that is IDK quite yet because I've been hammering at this long enough and I > need a break. > This is consistent with another observation about this particular test. If > there's sleep at the end, it wouldn't fail; all the reloads get a chance to > finish before anything was shut down. > An open question how much this matters to production systems. In the testing > case, bunches of these reloads are issued then we immediately end the test > and start shutting things down. It needs to be fixed if we're going to cut > down on test failures though. Besides, it's just wrong ;) > Assigning to myself to track. I'd be perfectly happy, now that Noble and I > have done the hard work, for someone to swoop in and take the credit for > fixing it ;) > gradlew beast -Ptests.dups=10 --tests TestBulkSchemaConcurrent > always fails for me on current code without my hack... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [lucene-solr] wojtek2kdev commented on pull request #1779: LUCENE-9478: Prevent DWPTDeleteQueue from referencing itself and leaking memory
wojtek2kdev commented on pull request #1779: URL: https://github.com/apache/lucene-solr/pull/1779#issuecomment-703167332 Hello, I'm newbie in Apache Lucene-Solr. Can someone explain me this bug as for kid? How can I reproduce it on my computer? I want to start participate by bug fixing, but at first I wanna check how previous issues was patched. Thanks in advance! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9560) Position aware TermQuery
Haoyu Zhai created LUCENE-9560:
--
Summary: Position aware TermQuery
Key: LUCENE-9560
URL: https://issues.apache.org/jira/browse/LUCENE-9560
Project: Lucene - Core
Issue Type: New Feature
Components: core/search
Reporter: Haoyu Zhai
In our work, we index most of our fields into an "all" field (like
elasticsearch) to make our search faster. But at the same time we still want to
support some of the field specific search (like {{title}}), so currently our
solution is to double index them so that we could do both "all" search as well
as specific field search.
I want to propose a new term query that accept a range in a specific field to
search so that we could search on "all" field but act like a field specific
search. Then we need not to doubly index those field.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14901) TestPackages uses binary precompiled classes to refer to analysis factory FQCNs
[
https://issues.apache.org/jira/browse/SOLR-14901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207086#comment-17207086
]
Noble Paul commented on SOLR-14901:
---
[~dweiss]
I think you are confused about what the test does.
it's not about signing those jars. Those classes "should not" be in classpath.
If they're in the classpath already, we never know if the feature is indeed
working or not.
> TestPackages uses binary precompiled classes to refer to analysis factory
> FQCNs
> ---
>
> Key: SOLR-14901
> URL: https://issues.apache.org/jira/browse/SOLR-14901
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Noble Paul
>Priority: Minor
>
> Base analysis factories' package name were renamed in [LUCENE-9317].
> {{o.a.s.pkg.TestPackages}} is failing since it has hard coded their old
> FQCNs, that needs to be fixed.
> See https://github.com/apache/lucene-solr/pull/1836 for details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9559) fix "gradle eclipse" to build in eclipse again
[
https://issues.apache.org/jira/browse/LUCENE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207087#comment-17207087
]
Noble Paul commented on LUCENE-9559:
Those files are not used. They're for documentation purposes only. I can rename
them to {{.txt}} file and it should be fine. Even if all the java files are
removed, the tests will continue to work
> fix "gradle eclipse" to build in eclipse again
> --
>
> Key: LUCENE-9559
> URL: https://issues.apache.org/jira/browse/LUCENE-9559
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Robert Muir
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-9559.patch, compilefailure.png
>
>
> The current "gradle eclipse" produces a non-working setup: you have
> compilation errors because of some java files in solr's {{test-files}} that
> don't compile.
> eclipse doesn't differentiate between a resource folder and a sources folder,
> classpath entries are just "src" and it tries to compile the java files it
> sees in there, which fails.
> So let's tell it not to compile them so that gradle eclipse works again: I
> don't know what crazy stuff solr is doing here, but i want the IDE to work
> again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul opened a new pull request #1945: SOLR-14680: revertfrom 8x
noblepaul opened a new pull request #1945: URL: https://github.com/apache/lucene-solr/pull/1945 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
