[jira] [Commented] (LUCENE-9493) Remove obsolete dev-tools/{idea,netbeans,maven} folders
[
https://issues.apache.org/jira/browse/LUCENE-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191001#comment-17191001
]
Dawid Weiss commented on LUCENE-9493:
-
Those things can be set up as part of IntelliJ idea plugin import, I believe...
but it would have to be written. I'd move those files to
gradle/ide/intellij-idea/ though, for consistency.
> Remove obsolete dev-tools/{idea,netbeans,maven} folders
> ---
>
> Key: LUCENE-9493
> URL: https://issues.apache.org/jira/browse/LUCENE-9493
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I don't think they're used or applicable anymore. Thoughts?
--
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-9461) Query hit highlighting components on top of matches API
[ https://issues.apache.org/jira/browse/LUCENE-9461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191003#comment-17191003 ] Dawid Weiss commented on LUCENE-9461: - I don't mind reuse. I would mind if the result of this would mean increasing their complexity. Right now they're really simple and detached from each other which allows for a variety of use cases to be implemented. The example is already there - the test shows at least one use case that's not possible with current highlighters (highlighting multiple queries at once). https://github.com/dweiss/lucene-solr/blob/LUCENE-9464/lucene/highlighter/src/test/org/apache/lucene/search/matchhighlight/TestMatchHighlighter.java#L118-L400 > Query hit highlighting components on top of matches API > --- > > Key: LUCENE-9461 > URL: https://issues.apache.org/jira/browse/LUCENE-9461 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: master (9.0) > > > Highlighters. Eventually, you'll have to face them. > When a Lucene Query is ran over an index, it implies a list of documents that > "matched it" - literally a boolean indication of whether the document should > be included in the search result or not. In practice, many applications need > to convey to users not just the fact that a document matched the query but > also some sort of intuitive explanation of *why* this particular query > matched it. While in many cases the relationship is trivial (term > containment), in case of complex queries it may not be trivial at all (think > of a really short prefix query, a fuzzy term query or even a Boolean > disjunction with a high number of possibilities). > Historically, search engines used to "highlight" the source area of a > document that caused the "hit". If a document was too long, it was truncated > and only the area around the hit (or hits) was displayed (so called > "snippet"). > In my subjective opinion, in the Lucene API highlighters have played a > secondary role to queries and search. And once you're trying to build > something higher-level, highlighters are a crucial and necessary element of > the entire system. > My experience (and users feedback) from an implementation of a document > retrieval system where highlighting was involved was that it just didn't work > as expected. Here are the requirements of that system: > * the query parser uses default field expansion into multiple fields (there > is no single "sink" field), > * the highlights should match *exactly* what caused the hit; a search for > 'title:foo' must not highlight foo in any other field, > * the set of fields to be highlighted isn't really fixed - there are some > fields that should always be displayed - title, summary - and others that > should not be displayed unless they're part of the query (in which case the > highlight is important and should be shown to the user). > * highlights should be accurate for all sorts of queries: fuzzy, phrase, > prefix, Boolean, spans, etc., > * there can be more than one query at one time and they should highlight the > same content (with different colors). > Many highlighters are available in Lucene (vector highlighter, postings > highlighter, unified highlighter) but none of them quite fit the bill above. > Believe me - we have tried (hard). We ended up using unified highlighter but > with subclassing, customizations and all sorts of complex, low-level quirks. > My gut feeling at that point was that it should be the Query that somehow > *exposes* the information about how a given field content matched. Then I > looked at matches API and built a quick prototype retrieving "match regions" > on top of that. It works like magic. Here are the key insights: > * matches API returns exactly what a highlighter needs: for a given query it > iterates over fields and positions (including offsets, if they are available) > that caused a document to be included in the search result, > * when matches API cannot provide offsets, it provides elements from which > offsets can be computed: positions by re-analyzing the field's value, for > example. > * in extreme cases it may happen the matches API doesn't provide anything > useful (a field only indexed, with no stored field value, no positions, no > offsets) but I assume it is up to the application layer to know how to deal > with this then (or not deal with it at all and throw an exception). > * matches API delegates the work of providing proper match ranges to the > query itself (actually, to the weight a query produces), it doesn't need to > know anything about different implementations and their specifics. > The absolute *key* element is the last one. Once you bui
[jira] [Commented] (LUCENE-9498) Move matchhighlighter to a separate subproject
[
https://issues.apache.org/jira/browse/LUCENE-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191007#comment-17191007
]
Dawid Weiss commented on LUCENE-9498:
-
Weird or not, it doesn't pull in two additional JARs which does matter if
you're using it in other projects. Smaller footprint, less to think about. Fine
though, let's postpone.
> Move matchhighlighter to a separate subproject
> --
>
> Key: LUCENE-9498
> URL: https://issues.apache.org/jira/browse/LUCENE-9498
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
>
> This is a trivial thing to do (on master at least). Match highlighter has no
> other dependencies. It sort of fits in the "highlighter" package but this
> package depends on {{queries}} and {{memory}} packages. I wonder if we should
> move it to a separate subproject?
--
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-9498) Move matchhighlighter to a separate subproject
[
https://issues.apache.org/jira/browse/LUCENE-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-9498.
-
Resolution: Later
> Move matchhighlighter to a separate subproject
> --
>
> Key: LUCENE-9498
> URL: https://issues.apache.org/jira/browse/LUCENE-9498
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
>
> This is a trivial thing to do (on master at least). Match highlighter has no
> other dependencies. It sort of fits in the "highlighter" package but this
> package depends on {{queries}} and {{memory}} packages. I wonder if we should
> move it to a separate subproject?
--
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-14794) Pass global cloud configuration to Collection API command execution
[
https://issues.apache.org/jira/browse/SOLR-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191010#comment-17191010
]
Noble Paul commented on SOLR-14794:
---
-1
please revert this. This is another frankestein change you are doing . This is
totally unwarranted.
> Pass global cloud configuration to Collection API command execution
> ---
>
> Key: SOLR-14794
> URL: https://issues.apache.org/jira/browse/SOLR-14794
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: config-api, SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, configuration, solr.xml, solrcloud
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Overseer has access to {{CloudConfig}} (a {{SolrCloud}} specific
> configuration subsection of {{solr.xml}}).
> The replacement of the Autoscaling framework in 9.0 (being worked on in
> SOLR-14613) requires access to SolrCloud configuration for placement
> decisions.
> This Jira is about making {{CloudConfig}} available to Collection API (or
> Config Set API) command execution in general.
--
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-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191009#comment-17191009
]
Johannes Baiter commented on SOLR-14829:
{quote}Would you like to open a new JIRA issue on those concerns so that I can
invite a wider discussion around it from some of the committers who are in the
best position to resolve this
{quote}
Sure, I'll try to get a better picture of the code/architecture first, though,
so I have a better picture of it and am not just ranting based on some
superficial observations :-)
{quote}In your own/custom definition of your request handler, do you need to
actually list these components at all, vs just rely on the default list? I
think most people by far let the defaults happen.
{quote}
Yeah, in my case I have a custom highlight component that I want to have on my
handler. Sure, there's {{first-components}} and {{last-components}}, which
would probably better for this case.
But I think we can agree that if there's an option to define your own
{{components}}, the documentation on the defaults for this option should be
correct so that users can operate under the right assumptions? Especially since
the documentation treats {{first-components}}, {{last-components}} and
{{components}} as equals, i.e. there's no comment indicating that the former
two might be preferable because they're "safer"?
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, examples
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
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] [Comment Edited] (SOLR-14794) Pass global cloud configuration to Collection API command execution
[
https://issues.apache.org/jira/browse/SOLR-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191010#comment-17191010
]
Noble Paul edited comment on SOLR-14794 at 9/5/20, 8:27 AM:
-1
please revert this. This is another frankenstein change you are doing . This is
totally unwarranted.
solr.xml should be deprecated and removed and it should not be made so pervasive
was (Author: noble.paul):
-1
please revert this. This is another frankestein change you are doing . This is
totally unwarranted.
> Pass global cloud configuration to Collection API command execution
> ---
>
> Key: SOLR-14794
> URL: https://issues.apache.org/jira/browse/SOLR-14794
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: config-api, SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, configuration, solr.xml, solrcloud
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Overseer has access to {{CloudConfig}} (a {{SolrCloud}} specific
> configuration subsection of {{solr.xml}}).
> The replacement of the Autoscaling framework in 9.0 (being worked on in
> SOLR-14613) requires access to SolrCloud configuration for placement
> decisions.
> This Jira is about making {{CloudConfig}} available to Collection API (or
> Config Set API) command execution in general.
--
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-14794) Pass global cloud configuration to Collection API command execution
[
https://issues.apache.org/jira/browse/SOLR-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191024#comment-17191024
]
Ilan Ginzburg commented on SOLR-14794:
--
[~noble.paul] this was reverted 3 days ago, the Jira was then resolved to
"Abandoned".
> Pass global cloud configuration to Collection API command execution
> ---
>
> Key: SOLR-14794
> URL: https://issues.apache.org/jira/browse/SOLR-14794
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: config-api, SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, configuration, solr.xml, solrcloud
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Overseer has access to {{CloudConfig}} (a {{SolrCloud}} specific
> configuration subsection of {{solr.xml}}).
> The replacement of the Autoscaling framework in 9.0 (being worked on in
> SOLR-14613) requires access to SolrCloud configuration for placement
> decisions.
> This Jira is about making {{CloudConfig}} available to Collection API (or
> Config Set API) command execution in general.
--
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-9493) Remove obsolete dev-tools/{idea,netbeans,maven} folders
[
https://issues.apache.org/jira/browse/LUCENE-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191025#comment-17191025
]
Tomoko Uchida commented on LUCENE-9493:
---
Thanks, I would prefer to keep the setups for idea.
> Remove obsolete dev-tools/{idea,netbeans,maven} folders
> ---
>
> Key: LUCENE-9493
> URL: https://issues.apache.org/jira/browse/LUCENE-9493
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I don't think they're used or applicable anymore. Thoughts?
--
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-14794) Pass global cloud configuration to Collection API command execution
[
https://issues.apache.org/jira/browse/SOLR-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191038#comment-17191038
]
Noble Paul commented on SOLR-14794:
---
Thanks Ilan , sorry for the confusion
> Pass global cloud configuration to Collection API command execution
> ---
>
> Key: SOLR-14794
> URL: https://issues.apache.org/jira/browse/SOLR-14794
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: config-api, SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, configuration, solr.xml, solrcloud
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Overseer has access to {{CloudConfig}} (a {{SolrCloud}} specific
> configuration subsection of {{solr.xml}}).
> The replacement of the Autoscaling framework in 9.0 (being worked on in
> SOLR-14613) requires access to SolrCloud configuration for placement
> decisions.
> This Jira is about making {{CloudConfig}} available to Collection API (or
> Config Set API) command execution in general.
--
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] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483944202
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -29,50 +33,117 @@ buildscript {
}
}
-configure(rootProject) {
- task("validateSourcePatterns", type: ValidateSourcePatternsTask) { task ->
+def extensions = [
+'adoc',
+'bat',
+'cmd',
+'css',
+'g4',
+'gradle',
+'groovy',
+'html',
+'java',
+'jflex',
+'jj',
+'js',
+'json',
+'mdtext',
+'pl',
+'policy',
+'properties',
+'py',
+'sh',
+'template',
+'vm',
+'xml',
+'xsl',
+]
+
+// Create source validation task local for each project's files.
+subprojects {
+ task validateSourcePatterns(type: ValidateSourcePatternsTask) { task ->
group = 'Verification'
description = 'Validate Source Patterns'
// This task has no proper outputs.
setupDummyOutputs(task)
-sourceFiles = project.fileTree(project.rootDir) {
- [
-'java', 'jflex', 'py', 'pl', 'g4', 'jj', 'html', 'js',
-'css', 'xml', 'xsl', 'vm', 'sh', 'cmd', 'bat', 'policy',
-'properties', 'mdtext', 'groovy', 'gradle',
-'template', 'adoc', 'json',
- ].each{
-include "lucene/**/*.${it}"
-include "solr/**/*.${it}"
-include "dev-tools/**/*.${it}"
-include "gradle/**/*.${it}"
+sourceFiles = fileTree(projectDir) {
+ extensions.each{
+include "*.${it}"
+ }
+
+ // default excludes.
Review comment:
I agree with this. Maybe make a closure out of it, so it can be applied
everywhere. I can do this, if you like.
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] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483944258
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -29,50 +33,117 @@ buildscript {
}
}
-configure(rootProject) {
- task("validateSourcePatterns", type: ValidateSourcePatternsTask) { task ->
+def extensions = [
+'adoc',
+'bat',
+'cmd',
+'css',
+'g4',
+'gradle',
+'groovy',
+'html',
+'java',
+'jflex',
+'jj',
+'js',
+'json',
+'mdtext',
+'pl',
+'policy',
+'properties',
+'py',
+'sh',
+'template',
+'vm',
+'xml',
+'xsl',
+]
+
+// Create source validation task local for each project's files.
+subprojects {
+ task validateSourcePatterns(type: ValidateSourcePatternsTask) { task ->
group = 'Verification'
description = 'Validate Source Patterns'
// This task has no proper outputs.
setupDummyOutputs(task)
-sourceFiles = project.fileTree(project.rootDir) {
- [
-'java', 'jflex', 'py', 'pl', 'g4', 'jj', 'html', 'js',
-'css', 'xml', 'xsl', 'vm', 'sh', 'cmd', 'bat', 'policy',
-'properties', 'mdtext', 'groovy', 'gradle',
-'template', 'adoc', 'json',
- ].each{
-include "lucene/**/*.${it}"
-include "solr/**/*.${it}"
-include "dev-tools/**/*.${it}"
-include "gradle/**/*.${it}"
+sourceFiles = fileTree(projectDir) {
+ extensions.each{
+include "*.${it}"
+ }
+
+ // default excludes.
+ exclude "$buildDir/**"
+ exclude '**/dist/**'
+ exclude 'dev-tools/missing-doclet/src/**/*.java' // <-- TODO: remove
once we allow "var" on master
+ exclude 'lucene/benchmark/work/**'
Review comment:
this wont work in per directory setting -> remove
same for solr a bit down.
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
I would keep this as debug or remove after adding the progress meter.
I often try to run gradlew with `--info`, but theis is way too much
information.
Do you know how to silence the palantir version-lock checker? I hate that it
prints so much information during configuration phase to info.
I'd like to enable `--info` on jenkins, but that's way to much.
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -29,50 +33,117 @@ buildscript {
}
}
-configure(rootProject) {
- task("validateSourcePatterns", type: ValidateSourcePatternsTask) { task ->
+def extensions = [
+'adoc',
+'bat',
+'cmd',
+'css',
+'g4',
+'gradle',
+'groovy',
+'html',
+'java',
+'jflex',
+'jj',
+'js',
+'json',
+'mdtext',
+'pl',
+'policy',
+'properties',
+'py',
+'sh',
+'template',
+'vm',
+'xml',
+'xsl',
+]
+
+// Create source validation task local for each project's files.
+subprojects {
+ task validateSourcePatterns(type: ValidateSourcePatternsTask) { task ->
group = 'Verification'
description = 'Validate Source Patterns'
// This task has no proper outputs.
setupDummyOutputs(task)
-sourceFiles = project.fileTree(project.rootDir) {
- [
-'java', 'jflex', 'py', 'pl', 'g4', 'jj', 'html', 'js',
-'css', 'xml', 'xsl', 'vm', 'sh', 'cmd', 'bat', 'policy',
-'properties', 'mdtext', 'groovy', 'gradle',
-'template', 'adoc', 'json',
- ].each{
-include "lucene/**/*.${it}"
-include "solr/**/*.${it}"
-include "dev-tools/**/*.${it}"
-include "gradle/**/*.${it}"
+sourceFiles = fileTree(projectDir) {
+ extensions.each{
+include "*.${it}"
+ }
+
+ // default excludes.
+ exclude "$buildDir/**"
+ exclude '**/dist/**'
+ exclude 'dev-tools/missing-doclet/src/**/*.java' // <-- TODO: remove
once we allow "var" on master
+ exclude 'lucene/benchmark/work/**'
Review comment:
But if the code does not fail, mabe remove the exclude (outdated?).
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
Review comment:
Cool!
---
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483947654
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -29,50 +33,117 @@ buildscript {
}
}
-configure(rootProject) {
- task("validateSourcePatterns", type: ValidateSourcePatternsTask) { task ->
+def extensions = [
+'adoc',
+'bat',
+'cmd',
+'css',
+'g4',
+'gradle',
+'groovy',
+'html',
+'java',
+'jflex',
+'jj',
+'js',
+'json',
+'mdtext',
+'pl',
+'policy',
+'properties',
+'py',
+'sh',
+'template',
+'vm',
+'xml',
+'xsl',
+]
+
+// Create source validation task local for each project's files.
+subprojects {
+ task validateSourcePatterns(type: ValidateSourcePatternsTask) { task ->
group = 'Verification'
description = 'Validate Source Patterns'
// This task has no proper outputs.
setupDummyOutputs(task)
-sourceFiles = project.fileTree(project.rootDir) {
- [
-'java', 'jflex', 'py', 'pl', 'g4', 'jj', 'html', 'js',
-'css', 'xml', 'xsl', 'vm', 'sh', 'cmd', 'bat', 'policy',
-'properties', 'mdtext', 'groovy', 'gradle',
-'template', 'adoc', 'json',
- ].each{
-include "lucene/**/*.${it}"
-include "solr/**/*.${it}"
-include "dev-tools/**/*.${it}"
-include "gradle/**/*.${it}"
+sourceFiles = fileTree(projectDir) {
+ extensions.each{
+include "*.${it}"
+ }
+
+ // default excludes.
Review comment:
Please, go ahead and take over!
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] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483947676
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -29,50 +33,117 @@ buildscript {
}
}
-configure(rootProject) {
- task("validateSourcePatterns", type: ValidateSourcePatternsTask) { task ->
+def extensions = [
+'adoc',
+'bat',
+'cmd',
+'css',
+'g4',
+'gradle',
+'groovy',
+'html',
+'java',
+'jflex',
+'jj',
+'js',
+'json',
+'mdtext',
+'pl',
+'policy',
+'properties',
+'py',
+'sh',
+'template',
+'vm',
+'xml',
+'xsl',
+]
+
+// Create source validation task local for each project's files.
+subprojects {
+ task validateSourcePatterns(type: ValidateSourcePatternsTask) { task ->
group = 'Verification'
description = 'Validate Source Patterns'
// This task has no proper outputs.
setupDummyOutputs(task)
-sourceFiles = project.fileTree(project.rootDir) {
- [
-'java', 'jflex', 'py', 'pl', 'g4', 'jj', 'html', 'js',
-'css', 'xml', 'xsl', 'vm', 'sh', 'cmd', 'bat', 'policy',
-'properties', 'mdtext', 'groovy', 'gradle',
-'template', 'adoc', 'json',
- ].each{
-include "lucene/**/*.${it}"
-include "solr/**/*.${it}"
-include "dev-tools/**/*.${it}"
-include "gradle/**/*.${it}"
+sourceFiles = fileTree(projectDir) {
+ extensions.each{
+include "*.${it}"
+ }
+
+ // default excludes.
+ exclude "$buildDir/**"
+ exclude '**/dist/**'
+ exclude 'dev-tools/missing-doclet/src/**/*.java' // <-- TODO: remove
once we allow "var" on master
+ exclude 'lucene/benchmark/work/**'
Review comment:
Yup.
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] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483947729
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
The --info switch is verbose. I don't think there's much you can do
about it. I was thinking about it myself - perhaps we should devise our own
internal logging verbosity level (and log to lifecycle when it's enabled).
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] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483948687
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
Info is like ant always was. Except the shitty palantir logging. Can we
suppress this? I have all Gradle builds with info logging in jenkins, except
Lucene.
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] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483948782
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
I don't know how to do that, Uwe.
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] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483950589
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
Nevertheless, I'd change ours back to debug (it's really only for
debugging). If a violation happens, filename is printed anyways.
But we should change this now to not use relative paths anymore, because
it's hard to figure out where file is located. I can take care of that.
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] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483951824
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
Hmm... What do you mean by "not use relative paths"?
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] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483953027
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
When it reports a violation it's relative to basedir of file collection.
This was ok we with root level task, but should be changed now to just print
full path.
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] uschindler commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
uschindler commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483953027
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
When it reports a violation it's relative to basedir of file collection.
This was ok with root level task, but should be changed now to just print full
path.
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-14579) Comment SolrJ 'Utils' generic map functions
[ https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191082#comment-17191082 ] ASF subversion and git services commented on SOLR-14579: Commit 3d411abbdccbe423e1573b1b1a08173e5f6d4690 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3d411ab ] SOLR-14579: Comment SolrJ 'Utils' generic map functions > Comment SolrJ 'Utils' generic map functions > --- > > Key: SOLR-14579 > URL: https://issues.apache.org/jira/browse/SOLR-14579 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Megan Carey >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14579.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj > module to reduce warnings and improve code quality. > [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92] -- 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-14579) Comment SolrJ 'Utils' generic map functions
[ https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191081#comment-17191081 ] ASF subversion and git services commented on SOLR-14579: Commit f71ba62d4ae3100ffe54bdf5df8254e2bbf6ec9d in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f71ba62 ] SOLR-14579: Comment SolrJ 'Utils' generic map functions > Comment SolrJ 'Utils' generic map functions > --- > > Key: SOLR-14579 > URL: https://issues.apache.org/jira/browse/SOLR-14579 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Megan Carey >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14579.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj > module to reduce warnings and improve code quality. > [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92] -- 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] (SOLR-14579) Comment SolrJ 'Utils' generic map functions
[ https://issues.apache.org/jira/browse/SOLR-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14579. --- Resolution: Fixed OK, I think I got it right this time, just by applying the PR from [~megancarey] thanks! Should have just done that the first time. It was inconvenient to try to cherry pick from master to 8x because autoscaling was removed, so I did them independently in case people are wondering about the commit message. > Comment SolrJ 'Utils' generic map functions > --- > > Key: SOLR-14579 > URL: https://issues.apache.org/jira/browse/SOLR-14579 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Megan Carey >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14579.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Remove the map functions like `NEW_HASHMAP_FUN` from the Utils class in solrj > module to reduce warnings and improve code quality. > [https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L92] -- 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 commented on pull request #1592: SOLR-14579 First pass at dismantling Utils
ErickErickson commented on pull request #1592: URL: https://github.com/apache/lucene-solr/pull/1592#issuecomment-687632455 Fixed up as per Uwe's criticisms. 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 closed pull request #1592: SOLR-14579 First pass at dismantling Utils
ErickErickson closed pull request #1592: URL: https://github.com/apache/lucene-solr/pull/1592 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 #1834: Make sure to test normal scorers with asserting wrappers.
jpountz commented on a change in pull request #1834:
URL: https://github.com/apache/lucene-solr/pull/1834#discussion_r483967822
##
File path:
lucene/test-framework/src/java/org/apache/lucene/search/AssertingWeight.java
##
@@ -85,11 +85,18 @@ public long cost() {
@Override
public BulkScorer bulkScorer(LeafReaderContext context) throws IOException {
-BulkScorer inScorer = in.bulkScorer(context);
+BulkScorer inScorer;
+// We explicitly test both the delegate's bulk scorer, and also the normal
scorer.
+// This ensures that normal scorers are sometimes tested with an asserting
wrapper.
+if (random.nextBoolean()) {
+ inScorer = in.bulkScorer(context);
+} else {
+ inScorer = super.bulkScorer(context);
+}
Review comment:
I know of several tests that test first with a top-level query and then
with a filter to make sure that both the bulk scorer and the scorer are tested.
With this change, 50% of the time, we wouldn't be testing the bulk scorer, so I
wonder if we should replace `random.nextBoolean()` with `frequently()` or
something like that.
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] dweiss commented on a change in pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
dweiss commented on a change in pull request #1830:
URL: https://github.com/apache/lucene-solr/pull/1830#discussion_r483969650
##
File path: gradle/validation/validate-source-patterns.gradle
##
@@ -181,8 +252,13 @@ class ValidateSourcePatternsTask extends DefaultTask {
}
}
+ProgressLogger progress = progressLoggerFactory.newOperation(this.class)
+progress.start(this.name, this.name)
+
sourceFiles.each{ f ->
- logger.debug('Scanning source file: {}', f);
+ progress.progress("Scanning ${f.name}")
+ logger.info('Scanning source file: {}', f);
Review comment:
Doesn't the logger carry the information which project this is? This
should be sufficient to locate the file in question? I don't mind changing it
to an absolute path, but I think project + path should be enough to locate
something?
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-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191119#comment-17191119
]
Shashank Shekhar commented on SOLR-14723:
-
Thanks for the detailed steps Erick. I have forked the lucene-solr repo. I am
not familiar with patches so planning to create a PR. Will keep this thread
updated.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
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-14821) docValuesTermsFilter should support single-valued docValues fields
[
https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191125#comment-17191125
]
ASF subversion and git services commented on SOLR-14821:
Commit ecb8ca2fef7cf799e4c3921f0a8f271f5afe3c83 in lucene-solr's branch
refs/heads/master from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ecb8ca2 ]
SOLR-14821: {!terms} dVTFTL supports single-valued strings
Prior to this commit the docValuesTermsFilterTopLevel method of the
{!terms} query parser would return zero results when run against a
single-valued String. This commit fixes this by wrapping the
single-valued 'SortedDocValues' in a 'SortedSetDocValues' object.
> docValuesTermsFilter should support single-valued docValues fields
> --
>
> Key: SOLR-14821
> URL: https://issues.apache.org/jira/browse/SOLR-14821
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Anatolii Siuniaev
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-14821.patch
>
>
> SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter
> in TermsQParserPlugin. But now it supports only multi-valued docValues
> fields (i.e. SORTED_SET type DocValues)
> It doesn't work for single-valued docValues fields (i.e. SORTED type
> DocValues), though it should.
--
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] [Comment Edited] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191119#comment-17191119
]
Shashank Shekhar edited comment on SOLR-14723 at 9/5/20, 5:55 PM:
--
Thanks for the detailed steps Erick. I have forked the lucene-solr repo. I am
not familiar with patches so planning to create a PR. Will keep this thread
updated.
I have few questions:
# Should I do my changes on the master branch in my forked repo and raise a PR
against the master in main repo?
# Assuming answer to 1 is yes I should be able to import the project in my
intellij as a gradle project and have nothing to do with ant.
was (Author: shshnk28):
Thanks for the detailed steps Erick. I have forked the lucene-solr repo. I am
not familiar with patches so planning to create a PR. Will keep this thread
updated.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
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] [Comment Edited] (SOLR-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191119#comment-17191119
]
Shashank Shekhar edited comment on SOLR-14723 at 9/5/20, 5:55 PM:
--
Thanks for the detailed steps [~erickerickson] . I have forked the lucene-solr
repo. I am not familiar with patches so planning to create a PR. Will keep this
thread updated.
I have few questions:
# Should I do my changes on the master branch in my forked repo and raise a PR
against the master in main repo?
# Assuming answer to 1 is yes I should be able to import the project in my
intellij as a gradle project and have nothing to do with ant.
was (Author: shshnk28):
Thanks for the detailed steps Erick. I have forked the lucene-solr repo. I am
not familiar with patches so planning to create a PR. Will keep this thread
updated.
I have few questions:
# Should I do my changes on the master branch in my forked repo and raise a PR
against the master in main repo?
# Assuming answer to 1 is yes I should be able to import the project in my
intellij as a gradle project and have nothing to do with ant.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
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] uschindler commented on pull request #1830: LUCENE-9506: Gradle: split validateSourcePatterns into per-project an…
uschindler commented on pull request #1830: URL: https://github.com/apache/lucene-solr/pull/1830#issuecomment-687643213 Not sure how this is logged. I will check tomorrow. 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-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191128#comment-17191128
]
Erick Erickson commented on SOLR-14723:
---
Well, at this point you _can't_ have anything to do with ant on master, that
support was removed a few days ago, so the answer to <2> is easy ;)
<1>: yes. Although you shouldn't really have to do anything specific to raise a
PR. If you title your PR "SOLR-14723: Remove the class atribute for the caches
in the _default/example configsets", magic happens and a few minutes later the
PR will automatically appear on this JIRA. It can be a little hard to find,
I've overlooked a PR a bunch of times. If it doesn't occur, then you can go
ahead and reference it in comments... Really, only the "SOLR-14723: " part is
necessary in the title.
Oh, and it's usually the responsibility of the committer to backport changes to
8x so don't worry about that.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
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] arafalov commented on pull request #1827: SOLR-14792: Remove VelocityResponseWriter
arafalov commented on pull request #1827: URL: https://github.com/apache/lucene-solr/pull/1827#issuecomment-687685130 Reviewing leftover references: The /browse is still mentioned in the following files: - example/files/README.txt (actually that is broken even in released Solr) - solr/solr-ref-guide/src/solr-tutorial.adoc - solr/solr-ref-guide/src/initparams-in-solrconfig.adoc - solr/solr-ref-guide/src/rule-based-authorization-plugin.adoc Looks ok otherwise, apart from accidentally check-ins. 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-14821) docValuesTermsFilter should support single-valued docValues fields
[
https://issues.apache.org/jira/browse/SOLR-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191176#comment-17191176
]
ASF subversion and git services commented on SOLR-14821:
Commit de06e660d2a82e272519977f669e42664b782605 in lucene-solr's branch
refs/heads/branch_8x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=de06e66 ]
SOLR-14821: {!terms} dVTFTL supports single-valued strings
Prior to this commit the docValuesTermsFilterTopLevel method of the
{!terms} query parser would return zero results when run against a
single-valued String. This commit fixes this by wrapping the
single-valued 'SortedDocValues' in a 'SortedSetDocValues' object.
> docValuesTermsFilter should support single-valued docValues fields
> --
>
> Key: SOLR-14821
> URL: https://issues.apache.org/jira/browse/SOLR-14821
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Anatolii Siuniaev
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-14821.patch
>
>
> SOLR-13890 introduced a post-filter implementation for docValuesTermsFilter
> in TermsQParserPlugin. But now it supports only multi-valued docValues
> fields (i.e. SORTED_SET type DocValues)
> It doesn't work for single-valued docValues fields (i.e. SORTED type
> DocValues), though it should.
--
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] (SOLR-5335) Add support for "default" operator
[ https://issues.apache.org/jira/browse/SOLR-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-5335. - Resolution: Information Provided > Add support for "default" operator > -- > > Key: SOLR-5335 > URL: https://issues.apache.org/jira/browse/SOLR-5335 > Project: Solr > Issue Type: Sub-task >Reporter: Steven Bower >Priority: Major > > In cases where a value is missing it expressions just simply don't return a > value and are considered "missing".. eg add( fieldA, fieldB) if fieldB > doesn't exist in a doc the "add" is considered missing. Would be nice to have > a "default" operator to handle edge cases.. eg add( fieldA, default( fieldB, > 0 )) such that the value 0 will be used instead of a "missing" value.. > This could also handle the div by zero case too -- 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] (SOLR-14834) Update all public-visible links from wiki.apache.org to RefGuide or cwiki
Alexandre Rafalovitch created SOLR-14834: Summary: Update all public-visible links from wiki.apache.org to RefGuide or cwiki Key: SOLR-14834 URL: https://issues.apache.org/jira/browse/SOLR-14834 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Alexandre Rafalovitch There is no point pointing at the old wiki and it is not reasonable to expect users to try to track the links to the new references. Especially since hosted RefGuide does not allow full-text search yet. Do this only for information visible to the users, the rest can be a separate JIRA. I am aware that we don't yet support RefGuide version locks in URLs (see SOLR-11143), but even doing latest-version links is already useful and will at least do the hard part of resolving all the corresponding URLs from old wiki to RefGuide (or cwiki if any). -- 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] (SOLR-14834) Update all public-visible links from wiki.apache.org to RefGuide or cwiki
[ https://issues.apache.org/jira/browse/SOLR-14834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch reassigned SOLR-14834: Assignee: Alexandre Rafalovitch > Update all public-visible links from wiki.apache.org to RefGuide or cwiki > - > > Key: SOLR-14834 > URL: https://issues.apache.org/jira/browse/SOLR-14834 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > > There is no point pointing at the old wiki and it is not reasonable to expect > users to try to track the links to the new references. Especially since > hosted RefGuide does not allow full-text search yet. > Do this only for information visible to the users, the rest can be a separate > JIRA. > I am aware that we don't yet support RefGuide version locks in URLs (see > SOLR-11143), but even doing latest-version links is already useful and will > at least do the hard part of resolving all the corresponding URLs from old > wiki to RefGuide (or cwiki if any). -- 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-14829) Default components are missing facet_module and terms in documentation
[
https://issues.apache.org/jira/browse/SOLR-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191200#comment-17191200
]
David Smiley commented on SOLR-14829:
-
bq. Yeah, in my case I have a custom highlight component that I want to have on
my handler.
Is it enough to merely define your search component with the name "highlight"
in solrconfig.xml, thus overriding the built-in one? Then you don't even need
to make any component changes to your handler definition.
bq. But I think we can agree that if there's an option to define your own
components, the documentation on the defaults for this option should be correct
so that users can operate under the right assumptions
Of course!
> Default components are missing facet_module and terms in documentation
> --
>
> Key: SOLR-14829
> URL: https://issues.apache.org/jira/browse/SOLR-14829
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, examples
>Affects Versions: 8.6.2
>Reporter: Johannes Baiter
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: SOLR-14829.patch
>
>
> In the reference guide, the list of search components that are enabled by
> default is missing the {{facet_module}} and {{terms}} components. The terms
> component is instead listed under "other useful components", while the
> {{FacetModule}} is never listed anywhere in the documentation, despite it
> being neccessary for the JSON Facet API to work.
> This is also how I stumbled upon this, I spent hours trying to figure out why
> JSON-based faceting was not working with my setup, after taking a glance at
> the {{SearchHandler}} source code based on a hunch, it became clear that my
> custom list of search components (created based on the list in the reference
> guide) was to blame.
> A patch for the documentation gap is attached, but I think there are some
> other issues with the naming/documentation around the two faceting APIs that
> may be worth discussing:
> * The names {{facet_module}} / {{FacetModule}} are very misleading, since
> the documentation is always talking about the "JSON Facet API", but the term
> "JSON" does not appear in the name of the component nor does the component
> have any documentation attached that mentions this
> * Why is the {{FacetModule}} class located in the {{search.facet}} package
> while every single other search component included in the core is located in
> the {{handler.component}} package?
--
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
