[jira] [Commented] (SOLR-14782) QueryElevationComponent does not handle escaped query terms

[Bruno Roustant (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187479#comment-17187479
 ] 

Bruno Roustant commented on SOLR-14782:
---

Looking into this.

> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
>  Labels: elevation
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa 
> bbb"{color}><{color:#0033b3}doc 
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2" 
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component 
> "QueryElevationComponent" does not unescape the query term bevor the lookup 
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>  



--
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-14782) QueryElevationComponent does not handle escaped query terms

[Bruno Roustant (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno Roustant reassigned SOLR-14782:
-

Assignee: Bruno Roustant

> QueryElevationComponent does not handle escaped query terms
> ---
>
> Key: SOLR-14782
> URL: https://issues.apache.org/jira/browse/SOLR-14782
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.2
>Reporter: Thomas Schmiereck
>Assignee: Bruno Roustant
>Priority: Major
>  Labels: elevation
>
> h1. Description
> if the elevate.xml contains a entry with spaces:
> <{color:#0033b3}query {color}{color:#174ad4}text{color}{color:#067d17}="aaa 
> bbb"{color}><{color:#0033b3}doc 
> {color}{color:#174ad4}id{color}{color:#067d17}="core2docId2" 
> {color}/>
> and the Solr query term is escaped:
> {{?q=aaa\+bbb}}
> the Solr search itself handels this correctly, but the elevate component 
> "QueryElevationComponent" does not unescape the query term bevor the lookup 
> in the elevate.xml.
> Result is that the entry is not elevated.
> A also valid (not escaped) query like:
> {{?q=aaa%20bbb}}
> is working.
> h1. Technical Notes
> see:
> org.apache.solr.handler.component.QueryElevationComponent.MapElevationProvider#getElevationForQuery
>  



--
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] chatman commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

chatman commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683586352


   I see. In that case, the way forward should be to maybe use Solr.XML only
   for now to unblock you, but revisit it later to leverage clusterprops
   before the release. @noble, is that okay for you?
   
   On Mon, 31 Aug, 2020, 11:54 am Ilan Ginzburg, 
   wrote:
   
   > Ishan, Noble is suggesting not to use solr.xml and hard code the plugin to
   > use if I understand his point correctly.
   >
   > What you suggest is how it’s in the PR: legacy will be used unless plugins
   > are defined in solr.xml (or if the Collection has rules).
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   



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] murblanc commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683584869


   Ishan, Noble is suggesting not to use solr.xml and hard code the plugin to 
use if I understand his point correctly.
   
   What you suggest is how it’s in the PR: legacy will be used unless plugins 
are defined in solr.xml (or if the Collection has rules).



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] murblanc commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683584098


   I did answer above your comment and alternate proposal about fetching 
property values. I believe our users will not be tormented if we provide them 
an efficient implementation.
   
   I’d be happy to change the current proposal for something easier to use (not 
pretending it’s perfect) but I’m not willing to sacrifice on performance in 
order to do so.



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] chatman commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

chatman commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683582331


   Legacy can be hard-coded. It will be used Unless overridden by solr.xml (to
   use something else).
   
   On Mon, 31 Aug, 2020, 11:41 am Ilan Ginzburg, 
   wrote:
   
   > If we hard code a default plugin, how do users get to chose if they’d
   > rather keep legacy or rules based assign instead? How do they pass
   > parameters to the plugin?
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   



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] murblanc commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683580121


   If we hard code a default plugin, how do users get to chose if they’d rather 
keep legacy or rules based assign instead? How do they pass parameters to the 
plugin?
   



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] noblepaul edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

noblepaul edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683488170


   >There's no other place to set default config (not hard code!) for which 
placement plugin to use 
   
   What is wrong with hard coding?
   
   >t's easy to have a single PropertyValue interface with all possible getter 
methods and have all but one return an empty optional. 
   
   Easy ? The whole code looks pretty bad with a million properties and 
factories. This looks like we are building a J2EE project. Let's make life 
simple
   
   IMHO, this is made this like EJBs . I do not want this PR to be merged in 
the current form and torment our users



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] rmuir commented on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

rmuir commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683533223


   >> That check was added to make merging easier. See the related issues about 
it. I don't care.
   
   That is really wrong to do. If master is on java 11, then master is on java 
11. If i had more energy i would heavy commit the fix to master just for 
emphasis.
   
   Either we are on java 11 or we are stuck on java 8, not some hybrid mix in 
between.



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] (LUCENE-9490) gradlew checkMissingDocsDefault fails on JDK 15 or later

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187352#comment-17187352
 ] 

ASF subversion and git services commented on LUCENE-9490:
-

Commit 14df77295de3a646189d2885b1f15128591eb236 in lucene-solr's branch 
refs/heads/LUCENE-9215 from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=14df77295 ]

LUCENE-9490: Disable both tasks in :lucene:core on Java 15+


> gradlew checkMissingDocsDefault fails on JDK 15 or later
> 
>
> Key: LUCENE-9490
> URL: https://issues.apache.org/jira/browse/LUCENE-9490
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Dawid Weiss
>Priority: Major
>  Labels: Java15
> Attachments: LUCENE-9490.patch, screen-[1].png
>
>
> All Policeman Jenkins Jobs fail on the EA build with Java 15. Reason is that 
> the task {{checkMissingDocsDefault}} fails due to "missing documentation":
> {noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script 
> '/home/jenkins/workspace/Lucene-Solr-master-Linux/gradle/validation/missing-docs-check.gradle'
>  line: 105
> * What went wrong:
> Execution failed for task ':lucene:classification:checkMissingDocsDefault'.
> > Javadoc verification failed:
>   Traceback (most recent call last):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 388, in 
>   if checkPackageSummaries(sys.argv[1], level):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 368, in checkPackageSummaries
>   if checkClassSummaries(fullPath):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 227, in checkClassSummaries
>   raise RuntimeError('failed to locate javadoc item in %s, line %d? last 
> line: %s' % (fullPath, lineCount, line.rstrip()))
>   RuntimeError: failed to locate javadoc item in 
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/classification/build/docs/javadoc/org/apache/lucene/classification/ClassificationResult.html,
>  line 135? last line: 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}
> Interestingly, it doe snot fail on all subprojects. It looks like JDK15 
> changed the HTML output and so the checks are failing.
> With the Ant build this was not a problem, as we disabled this task (and all 
> other documentation-lint tasks), if running with an unsupported JDK version. 
> It's very har to rely on HTML output, as this can change on every JDK version.
> We have 2 options:
> - Maybe fix some regular expression in the python script (sorry I have no 
> idea on python and what's the problem)
> - Disable the python-linter tasks as we did in Ant, when the java version (of 
> RUNTIME_JAVA_HOME) is outside our expectations!
> My personal opinion is to handle this in same way like Ant: Disable the 
> documentation-linter for any RUNTIME_JAVA_HOME version later than our 
> supported one. Or maybe disable it always when we use an alternative JDK? 
> That's easiest to check when bulding task dependencies in Gradle, IMHO, 
> whenever an alternate Java Home is given. If the alternative JVM is the same 
> as Gradle's it would be kept enabled anyways, so the ideal place for this 
> would be here:
> https://github.com/apache/lucene-solr/blob/master/gradle/testing/alternative-jdk-support.gradle#L52-L71
> Just add another {{tasks.withType()}}. and set {{task.enabled = false}}.
> [~dawid.weiss], [~tomoko]: Any ideas or recommendation?



--
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-9456) Stored fields should store the number of chunks in the meta file

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187351#comment-17187351
 ] 

ASF subversion and git services commented on LUCENE-9456:
-

Commit 06903a40eefa619d0746d2351da6ce79d049b3b3 in lucene-solr's branch 
refs/heads/LUCENE-9215 from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=06903a4 ]

LUCENE-9456: fix DirectUpdateHandlerTest#testPrepareCommit (#1803)

Check for specific files being present or not or changing.  Don't make 
assumptions about file count.

> Stored fields should store the number of chunks in the meta file
> 
>
> Key: LUCENE-9456
> URL: https://issues.apache.org/jira/browse/LUCENE-9456
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.7
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently stored fields record numChunks/numDirtyChunks at the very end of 
> the data file. They should migrate to the meta file instead, so that they 
> would be validated when opening the index (meta files get their checksum 
> validated entirely, data files don't).



--
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-9215) replace checkJavaDocs.py with doclet

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187353#comment-17187353
 ] 

ASF subversion and git services commented on LUCENE-9215:
-

Commit 0a9c2a1abd9fb77d3821794afa136898a9f72934 in lucene-solr's branch 
refs/heads/LUCENE-9215 from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0a9c2a1 ]

Merge branch 'master' of https://gitbox.apache.org/repos/asf/lucene-solr into 
LUCENE-9215


> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error -

[GitHub] [lucene-solr] noblepaul edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

noblepaul edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683488170


   >There's no other place to set default config (not hard code!) for which 
placement plugin to use 
   
   What is wrong with hard coding?
   
   >t's easy to have a single PropertyValue interface with all possible getter 
methods and have all but one return an empty optional. 
   
   Easy ? The whole code looks pretty bad with a million properties and 
factories. This looks like we are building a J2EE project. Let's make life 
simple
   
   IMHO, you have made this like EJBs . I do not want this PR to be merged in 
the current form and torment our users



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] (LUCENE-9490) gradlew checkMissingDocsDefault fails on JDK 15 or later

[Uwe Schindler (Jira)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler resolved LUCENE-9490.
---
Resolution: Fixed

Should be OK now.

> gradlew checkMissingDocsDefault fails on JDK 15 or later
> 
>
> Key: LUCENE-9490
> URL: https://issues.apache.org/jira/browse/LUCENE-9490
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Dawid Weiss
>Priority: Major
>  Labels: Java15
> Attachments: LUCENE-9490.patch, screen-[1].png
>
>
> All Policeman Jenkins Jobs fail on the EA build with Java 15. Reason is that 
> the task {{checkMissingDocsDefault}} fails due to "missing documentation":
> {noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script 
> '/home/jenkins/workspace/Lucene-Solr-master-Linux/gradle/validation/missing-docs-check.gradle'
>  line: 105
> * What went wrong:
> Execution failed for task ':lucene:classification:checkMissingDocsDefault'.
> > Javadoc verification failed:
>   Traceback (most recent call last):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 388, in 
>   if checkPackageSummaries(sys.argv[1], level):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 368, in checkPackageSummaries
>   if checkClassSummaries(fullPath):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 227, in checkClassSummaries
>   raise RuntimeError('failed to locate javadoc item in %s, line %d? last 
> line: %s' % (fullPath, lineCount, line.rstrip()))
>   RuntimeError: failed to locate javadoc item in 
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/classification/build/docs/javadoc/org/apache/lucene/classification/ClassificationResult.html,
>  line 135? last line: 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}
> Interestingly, it doe snot fail on all subprojects. It looks like JDK15 
> changed the HTML output and so the checks are failing.
> With the Ant build this was not a problem, as we disabled this task (and all 
> other documentation-lint tasks), if running with an unsupported JDK version. 
> It's very har to rely on HTML output, as this can change on every JDK version.
> We have 2 options:
> - Maybe fix some regular expression in the python script (sorry I have no 
> idea on python and what's the problem)
> - Disable the python-linter tasks as we did in Ant, when the java version (of 
> RUNTIME_JAVA_HOME) is outside our expectations!
> My personal opinion is to handle this in same way like Ant: Disable the 
> documentation-linter for any RUNTIME_JAVA_HOME version later than our 
> supported one. Or maybe disable it always when we use an alternative JDK? 
> That's easiest to check when bulding task dependencies in Gradle, IMHO, 
> whenever an alternate Java Home is given. If the alternative JVM is the same 
> as Gradle's it would be kept enabled anyways, so the ideal place for this 
> would be here:
> https://github.com/apache/lucene-solr/blob/master/gradle/testing/alternative-jdk-support.gradle#L52-L71
> Just add another {{tasks.withType()}}. and set {{task.enabled = false}}.
> [~dawid.weiss], [~tomoko]: Any ideas or recommendation?



--
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-9490) gradlew checkMissingDocsDefault fails on JDK 15 or later

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187348#comment-17187348
 ] 

ASF subversion and git services commented on LUCENE-9490:
-

Commit 14df77295de3a646189d2885b1f15128591eb236 in lucene-solr's branch 
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=14df77295 ]

LUCENE-9490: Disable both tasks in :lucene:core on Java 15+


> gradlew checkMissingDocsDefault fails on JDK 15 or later
> 
>
> Key: LUCENE-9490
> URL: https://issues.apache.org/jira/browse/LUCENE-9490
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Dawid Weiss
>Priority: Major
>  Labels: Java15
> Attachments: LUCENE-9490.patch, screen-[1].png
>
>
> All Policeman Jenkins Jobs fail on the EA build with Java 15. Reason is that 
> the task {{checkMissingDocsDefault}} fails due to "missing documentation":
> {noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script 
> '/home/jenkins/workspace/Lucene-Solr-master-Linux/gradle/validation/missing-docs-check.gradle'
>  line: 105
> * What went wrong:
> Execution failed for task ':lucene:classification:checkMissingDocsDefault'.
> > Javadoc verification failed:
>   Traceback (most recent call last):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 388, in 
>   if checkPackageSummaries(sys.argv[1], level):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 368, in checkPackageSummaries
>   if checkClassSummaries(fullPath):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 227, in checkClassSummaries
>   raise RuntimeError('failed to locate javadoc item in %s, line %d? last 
> line: %s' % (fullPath, lineCount, line.rstrip()))
>   RuntimeError: failed to locate javadoc item in 
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/classification/build/docs/javadoc/org/apache/lucene/classification/ClassificationResult.html,
>  line 135? last line: 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}
> Interestingly, it doe snot fail on all subprojects. It looks like JDK15 
> changed the HTML output and so the checks are failing.
> With the Ant build this was not a problem, as we disabled this task (and all 
> other documentation-lint tasks), if running with an unsupported JDK version. 
> It's very har to rely on HTML output, as this can change on every JDK version.
> We have 2 options:
> - Maybe fix some regular expression in the python script (sorry I have no 
> idea on python and what's the problem)
> - Disable the python-linter tasks as we did in Ant, when the java version (of 
> RUNTIME_JAVA_HOME) is outside our expectations!
> My personal opinion is to handle this in same way like Ant: Disable the 
> documentation-linter for any RUNTIME_JAVA_HOME version later than our 
> supported one. Or maybe disable it always when we use an alternative JDK? 
> That's easiest to check when bulding task dependencies in Gradle, IMHO, 
> whenever an alternate Java Home is given. If the alternative JVM is the same 
> as Gradle's it would be kept enabled anyways, so the ideal place for this 
> would be here:
> https://github.com/apache/lucene-solr/blob/master/gradle/testing/alternative-jdk-support.gradle#L52-L71
> Just add another {{tasks.withType()}}. and set {{task.enabled = false}}.
> [~dawid.weiss], [~tomoko]: Any ideas or recommendation?



--
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 edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

noblepaul edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683488170


   >There's no other place to set default config (not hard code!) for which 
placement plugin to use 
   
   What is wrong with hard coding?
   
   >t's easy to have a single PropertyValue interface with all possible getter 
methods and have all but one return an empty optional. 
   
   Easy ? The whole code looks pretty bad with a million properties and 
factories. This looks like we are building a J2EE project. Let's make life 
simple



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] noblepaul commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

noblepaul commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683488170


   >There's no other place to set default config (not hard code!) for which 
placement plugin to use 
   
   What is wrong with hard coding?



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-6152) Pre-populating values into search parameters on the query page of solr admin

[Jakob Furrer (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187344#comment-17187344
 ] 

Jakob Furrer commented on SOLR-6152:


Can someone please change/update the affected versions of this ticket.
Currently I am not able to indicate that a new patch is ready for review 
because the respective button is not displayed.
Also: Please review/comment the patch from10th of August. Thanks.

> Pre-populating values into search parameters on the query page of solr admin
> 
>
> Key: SOLR-6152
> URL: https://issues.apache.org/jira/browse/SOLR-6152
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 4.3.1
>Reporter: Dmitry Kan
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: SOLR-6152.patch, SOLR-6152.patch, SOLR-6152.patch, 
> SOLR-6152.patch, copy_url_to_clipboard.png, copy_url_to_clipboard_v2.png, 
> prefilling_and_extending_the_multivalue_parameter_fq.png, 
> prepoluate_query_parameters_query_page.bmp
>
>
> In some use cases, it is highly desirable to be able to pre-populate the 
> query page of solr admin with specific values.
> In particular use case of mine, the solr admin user must pass a date range 
> value without which the query would fail.
> It isn't easy to remember the value format for non-solr experts, so I would 
> like to have a way of hooking that value "example" into the query page.
> See the screenshot attached, where I have inserted the fq parameter with date 
> range into the Raw Query Parameters.



--
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-9490) gradlew checkMissingDocsDefault fails on JDK 15 or later

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187345#comment-17187345
 ] 

Uwe Schindler commented on LUCENE-9490:
---

I know, it's the other task:

{noformat}
> Task :lucene:core:checkMissingDocsDefault SKIPPED
Skipping task because runtime Java version 15 is higher than Java 14.

> Task :lucene:core:checkMissingDocsMethod FAILED
{noformat}

Looks like both need to be disabled. Will commit a fix.

> gradlew checkMissingDocsDefault fails on JDK 15 or later
> 
>
> Key: LUCENE-9490
> URL: https://issues.apache.org/jira/browse/LUCENE-9490
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Dawid Weiss
>Priority: Major
>  Labels: Java15
> Attachments: LUCENE-9490.patch, screen-[1].png
>
>
> All Policeman Jenkins Jobs fail on the EA build with Java 15. Reason is that 
> the task {{checkMissingDocsDefault}} fails due to "missing documentation":
> {noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script 
> '/home/jenkins/workspace/Lucene-Solr-master-Linux/gradle/validation/missing-docs-check.gradle'
>  line: 105
> * What went wrong:
> Execution failed for task ':lucene:classification:checkMissingDocsDefault'.
> > Javadoc verification failed:
>   Traceback (most recent call last):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 388, in 
>   if checkPackageSummaries(sys.argv[1], level):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 368, in checkPackageSummaries
>   if checkClassSummaries(fullPath):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 227, in checkClassSummaries
>   raise RuntimeError('failed to locate javadoc item in %s, line %d? last 
> line: %s' % (fullPath, lineCount, line.rstrip()))
>   RuntimeError: failed to locate javadoc item in 
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/classification/build/docs/javadoc/org/apache/lucene/classification/ClassificationResult.html,
>  line 135? last line: 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}
> Interestingly, it doe snot fail on all subprojects. It looks like JDK15 
> changed the HTML output and so the checks are failing.
> With the Ant build this was not a problem, as we disabled this task (and all 
> other documentation-lint tasks), if running with an unsupported JDK version. 
> It's very har to rely on HTML output, as this can change on every JDK version.
> We have 2 options:
> - Maybe fix some regular expression in the python script (sorry I have no 
> idea on python and what's the problem)
> - Disable the python-linter tasks as we did in Ant, when the java version (of 
> RUNTIME_JAVA_HOME) is outside our expectations!
> My personal opinion is to handle this in same way like Ant: Disable the 
> documentation-linter for any RUNTIME_JAVA_HOME version later than our 
> supported one. Or maybe disable it always when we use an alternative JDK? 
> That's easiest to check when bulding task dependencies in Gradle, IMHO, 
> whenever an alternate Java Home is given. If the alternative JVM is the same 
> as Gradle's it would be kept enabled anyways, so the ideal place for this 
> would be here:
> https://github.com/apache/lucene-solr/blob/master/gradle/testing/alternative-jdk-support.gradle#L52-L71
> Just add another {{tasks.withType()}}. and set {{task.enabled = false}}.
> [~dawid.weiss], [~tomoko]: Any ideas or recommendation?



--
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] [Reopened] (LUCENE-9490) gradlew checkMissingDocsDefault fails on JDK 15 or later

[Uwe Schindler (Jira)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler reopened LUCENE-9490:
---

For some strange reason, the task still fails on Policeman Jenkins:
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/27841/console

Uwe

> gradlew checkMissingDocsDefault fails on JDK 15 or later
> 
>
> Key: LUCENE-9490
> URL: https://issues.apache.org/jira/browse/LUCENE-9490
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Dawid Weiss
>Priority: Major
>  Labels: Java15
> Attachments: LUCENE-9490.patch, screen-[1].png
>
>
> All Policeman Jenkins Jobs fail on the EA build with Java 15. Reason is that 
> the task {{checkMissingDocsDefault}} fails due to "missing documentation":
> {noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script 
> '/home/jenkins/workspace/Lucene-Solr-master-Linux/gradle/validation/missing-docs-check.gradle'
>  line: 105
> * What went wrong:
> Execution failed for task ':lucene:classification:checkMissingDocsDefault'.
> > Javadoc verification failed:
>   Traceback (most recent call last):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 388, in 
>   if checkPackageSummaries(sys.argv[1], level):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 368, in checkPackageSummaries
>   if checkClassSummaries(fullPath):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 227, in checkClassSummaries
>   raise RuntimeError('failed to locate javadoc item in %s, line %d? last 
> line: %s' % (fullPath, lineCount, line.rstrip()))
>   RuntimeError: failed to locate javadoc item in 
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/classification/build/docs/javadoc/org/apache/lucene/classification/ClassificationResult.html,
>  line 135? last line: 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}
> Interestingly, it doe snot fail on all subprojects. It looks like JDK15 
> changed the HTML output and so the checks are failing.
> With the Ant build this was not a problem, as we disabled this task (and all 
> other documentation-lint tasks), if running with an unsupported JDK version. 
> It's very har to rely on HTML output, as this can change on every JDK version.
> We have 2 options:
> - Maybe fix some regular expression in the python script (sorry I have no 
> idea on python and what's the problem)
> - Disable the python-linter tasks as we did in Ant, when the java version (of 
> RUNTIME_JAVA_HOME) is outside our expectations!
> My personal opinion is to handle this in same way like Ant: Disable the 
> documentation-linter for any RUNTIME_JAVA_HOME version later than our 
> supported one. Or maybe disable it always when we use an alternative JDK? 
> That's easiest to check when bulding task dependencies in Gradle, IMHO, 
> whenever an alternate Java Home is given. If the alternative JVM is the same 
> as Gradle's it would be kept enabled anyways, so the ideal place for this 
> would be here:
> https://github.com/apache/lucene-solr/blob/master/gradle/testing/alternative-jdk-support.gradle#L52-L71
> Just add another {{tasks.withType()}}. and set {{task.enabled = false}}.
> [~dawid.weiss], [~tomoko]: Any ideas or recommendation?



--
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-9475) Enhance the Gradle build as necessary after removing Ant support

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187342#comment-17187342
 ] 

Uwe Schindler commented on LUCENE-9475:
---

I created a pull request to change the checkSourcePatterns task to remove the 
{{}} ant magic and execute the task's groovy code directly.

> Enhance the Gradle build as necessary after removing Ant support
> 
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up 
> out of the cracks, especially as we try the first 9.0 release which will be 
> Gradle only. Here we list some of the areas we'll have to be aware of. Please 
> add as you see fit. Assigning to myself to track, but I certainly don't want 
> hog all the fun.
>  * Remove Maven support and replace with "The Gradle Way" of doing Maven. See 
> LUCENE-9077 (Dawid)
>  * 
>  ** Remove all of dev-tools/maven?
>  ** Other dev-tools files no longer used, check if any Gradle build file 
> references and remove if not.
>  * -Move Jenkins over to use Gradle only-
>  * -Verify reference guide build works under Gradle-
>  * Smoke tester
>  * Remove anything having to to with Clover (obsolete as of Java 11)
>  * -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} -
>  * Remove obsolete files in root dirs of lucene and solr (like 
> version.properties, now integrated into gradle)
>  * Remove Maven build files (obsolete with Gradle)
>  * Hoss's test rollups?
>  * Enable javadocs after ant stops being used (LUCENE-9441)
>  * fix some relative links in javadocs which contain ant module names (?)
>  * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, 
> and some in the README.md. This one should probably be its own JIRA since 
> it'll require quite a bit of verification...
>  * -Make "the best damn beasting script in the world" work with the Gradle 
> build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
>  * Update the release documentation to reflect Gradle (LUCENE-9488)
>  * Clean up anything in lucene/tools
>  * Clean up Confluence, in particular any page that mentions IDEs. The "How 
> to Contribute" page has several links to various bits and pieces of how to 
> use IDEs, and some mention ant.



--
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] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187342#comment-17187342
 ] 

Uwe Schindler edited comment on LUCENE-9475 at 8/30/20, 11:45 PM:
--

I created a pull request to change the checkSourcePatterns task to remove the 
{{}} ant magic and execute the task's groovy code directly: 
https://github.com/apache/lucene-solr/pull/1806


was (Author: thetaphi):
I created a pull request to change the checkSourcePatterns task to remove the 
{{}} ant magic and execute the task's groovy code directly.

> Enhance the Gradle build as necessary after removing Ant support
> 
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up 
> out of the cracks, especially as we try the first 9.0 release which will be 
> Gradle only. Here we list some of the areas we'll have to be aware of. Please 
> add as you see fit. Assigning to myself to track, but I certainly don't want 
> hog all the fun.
>  * Remove Maven support and replace with "The Gradle Way" of doing Maven. See 
> LUCENE-9077 (Dawid)
>  * 
>  ** Remove all of dev-tools/maven?
>  ** Other dev-tools files no longer used, check if any Gradle build file 
> references and remove if not.
>  * -Move Jenkins over to use Gradle only-
>  * -Verify reference guide build works under Gradle-
>  * Smoke tester
>  * Remove anything having to to with Clover (obsolete as of Java 11)
>  * -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} -
>  * Remove obsolete files in root dirs of lucene and solr (like 
> version.properties, now integrated into gradle)
>  * Remove Maven build files (obsolete with Gradle)
>  * Hoss's test rollups?
>  * Enable javadocs after ant stops being used (LUCENE-9441)
>  * fix some relative links in javadocs which contain ant module names (?)
>  * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, 
> and some in the README.md. This one should probably be its own JIRA since 
> it'll require quite a bit of verification...
>  * -Make "the best damn beasting script in the world" work with the Gradle 
> build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
>  * Update the release documentation to reflect Gradle (LUCENE-9488)
>  * Clean up anything in lucene/tools
>  * Clean up Confluence, in particular any page that mentions IDEs. The "How 
> to Contribute" page has several links to various bits and pieces of how to 
> use IDEs, and some mention ant.



--
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 opened a new pull request #1806: LUCENE-9475: Switch validateSourcePatters away from Ant legacy

[GitBox]

uschindler opened a new pull request #1806:
URL: https://github.com/apache/lucene-solr/pull/1806


   This PR changes the legacy setp of the checkSourcePatterns task to directly 
execute the checker code in the running Gradle VM.
   
   Because of Ant compatibility we preserved the old code using Ant's Groovy 
task. So it was executing Groovy shell inside Groovy. The code changes are 
minimal, further improvements are coming later.
   
   This task has no outputs, so itÄs declared to run always. We may improve 
this, if we make the checked files and patterns a task input. Quick tests on 
different branches showed that task works.



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683483373


   As this class is not part of any code in branch_8x, I think 
validateSourcePatterns should exclude it for this check. Can be quickyl 
implemented.
   
   I am dealing with validateSourcePatterns anyways, as it was not yet fully 
ported to Gradle (it causes a stupid warning due to duplicate task defs).



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 edited a comment on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler edited a comment on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683481056


   > seems the build fails because of var use? that check is broken: master is 
java 11
   
   That check was added to make merging easier. See the related issues about 
it. I don't care.
   
   Personally I am not a fan of `var`, but I don't care. For this case, I would 
just change the code, unless we have a decission in master. It should not block 
this merge.



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683481056


   > seems the build fails because of var use? that check is broken: master is 
java 11
   
   That check was added to make merging easier. See the related issues about 
it. I don't care.
   
   Personally I am not a fan of {{var}}, but I don't care. For this case, I 
would just change the code, unless we have a decission in master. It should not 
block this merge.



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] rmuir commented on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

rmuir commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683477788


   seems the build fails because of `var` use? that check is broken: master is 
java 11



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-14788) Solr: The Next Big Thing

[Mark Robert Miller (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187336#comment-17187336
 ] 

Mark Robert Miller commented on SOLR-14788:
---

Test are back to a pretty great state after the effort to wrap up major work 
and Tim's steady addition of Ignored tests.

Any fail you might run into is now of interest.

> Solr: The Next Big Thing
> 
>
> Key: SOLR-14788
> URL: https://issues.apache.org/jira/browse/SOLR-14788
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Robert Miller
>Priority: Critical
>
> I have stolen this title from Ishan or Noble and Ishan.
> This issue is meant to capture the work of a small team that is forming to 
> push Solr and SolrCloud to the next phase.
> I have kicked off the work with an effort to create a very fast and solid 
> base. That work is not 100% done, but it's ready to join the fight.
> Tim Potter has started giving me a tremendous hand in finishing up. Ishan and 
> Noble have already contributed support and testing and have plans for 
> additional work to shore up some of our current shortcomings.
> Others have expressed an interest in helping and hopefully they will pop up 
> here as well.
> Let's organize and discuss our efforts here and in various sub issues.



--
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 #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on a change in pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#discussion_r479814878



##
File path: gradle/validation/forbidden-apis.gradle
##
@@ -103,6 +103,13 @@ allprojects { prj ->
   ]
 }
 
+// Doclet does use exotic JDK APIs.

Review comment:
   No longer needed.





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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

dweiss commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683464627


   I did move it to a composite subproject. So it is now separate from Solr and 
Lucene, yet still in the source tree. We can move it back to buildSrc or 
anything else once it's ready and polished. For now, let's leave it as is - 
speeds up experimenting.



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

dweiss commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683463331


   A yet another alternative is to use a composite build to compile it locally. 
Then it is a separate project (top-level project) on its own and is not part of 
the Lucene/ Solr projects tree. This does take away some of the benefits I 
mentioned though.



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

dweiss commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683462911


   Making it a true project discovered two bugs the moment I tried to compile 
it. So there are benefits. It also makes development faster, at least in the 
early stage (because it doesn't invalidate caches). Sure we can externalize it 
as a separate dependency, I don't have a problem with this at all.



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683454888


   > If that's the case, I'd copypaste Robert's code into the 
render-javadocs.gradle file as another inner class (as the syntax of Java is 
mostly the same with Gradle).
   
   OK, this won't work, as javadoc is running as external tool and we need a 
classpath. But nevertheless, it shouldn't be in Lucene.
   
   Maybe we should do the same thing like with forbiddenapis:
   - If Robert agrees, we put it as a simple Maven Project (no Gradle needed) 
into https://github.com/policeman-tools as a new project, Robert is also part 
of that organization.
   - I can publish it on Maven using the Sonatype infrastructure afterwards:
   - Everybody can use it as its a plain JAR file that can be added to any 
Project (Ant, Maven, Gradle, or maybe also Bazel or Makefiles that invoke 
Javadocs) so it could also be used by others who want to do missing docs checks 
in Maven.



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] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Robert Muir (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187311#comment-17187311
 ] 

Robert Muir commented on LUCENE-9215:
-

if we can check javadocs without relying on override i think it is a win. even 
if we enforce overrides elsewhere with ecj. it could create confusing errors 
depending on the order that tasks are run and so on. just my thoughts on it.

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-sol

[GitHub] [lucene-solr] uschindler edited a comment on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler edited a comment on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683452425


   Hi,
   I still disagree. We have many classes in the build that are Groovy-based 
(like the javadocs task). What's the difference to that one, just because it's 
written in Java? If that's the case, I'd copypaste Robert's code into the 
render-javadocs.gradle file as another inner class (as the syntax of Java is 
mostly the same with Gradle).
   
   It also now produces Javadocs, it appears in documentation index, it 
produces artifacts,... It would really be easier if it would be part of the 
regular build infrastructure in build-src. I know from Elasticserach that they 
also run forbiddenapis checks there. Just declare and apply the plugin  and add 
one snippet to enable forbiddenapis for this one. I also don't like it to be 
not separated from the rest of the build. It's purely a build tool, so it 
should be in build-src or the grade subdirectory.
   
   Last but not least: It should not be below "lucene", as it will be useful 
for Solr, too (after split of projects).
   
   So please revert this commit, I disagree here. Maybe @rmuir has similar 
opinons.



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683452425


   Hi,
   I still disagree. We have many classes in the build that are Groovy, based 
(like the javadocs task). Wht's the difference to that on, just because it's 
written in Java. If that's the case, I'd copypaste Robert's code into the 
render-javadocs.gradle file (as the syntax of Java is mostly the same with 
Gradle).
   
   It also now produces Javadocs, it appears in documentation index, it 
produces artifacts,... It would really be easier if it would be part of the 
regular build infrastructure in build-src. I know from Elasticserach that they 
also run forbiddenapis checks there. Just declare and apply the plugin  and add 
one snippet to enable forbiddenapis for this one. I also don't like it to be 
not separated from the rest of the build. It's purely a build tool, so it 
should be in build-src or the grade subdirectory.
   
   Last but not least: It should not be below "lucene", as it will be useful 
for Solr, too (after split of projects).
   
   So please revert this commit, I disagree here. Maybe @rmuir has similar 
opinons.



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 edited a comment on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler edited a comment on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683452425


   Hi,
   I still disagree. We have many classes in the build that are Groovy-based 
(like the javadocs task). Wht's the difference to that on, just because it's 
written in Java. If that's the case, I'd copypaste Robert's code into the 
render-javadocs.gradle file (as the syntax of Java is mostly the same with 
Gradle).
   
   It also now produces Javadocs, it appears in documentation index, it 
produces artifacts,... It would really be easier if it would be part of the 
regular build infrastructure in build-src. I know from Elasticserach that they 
also run forbiddenapis checks there. Just declare and apply the plugin  and add 
one snippet to enable forbiddenapis for this one. I also don't like it to be 
not separated from the rest of the build. It's purely a build tool, so it 
should be in build-src or the grade subdirectory.
   
   Last but not least: It should not be below "lucene", as it will be useful 
for Solr, too (after split of projects).
   
   So please revert this commit, I disagree here. Maybe @rmuir has similar 
opinons.



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

dweiss commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683447537


   It's a bit of a chicken and egg problem (boostrapping gradle itself). I do 
think a separate project for this is beneficial here - at least it's clear what 
it is, has a (potentially) separate set of dependencies, runs checks much like 
anything else, etc. We don't have to name it "tools"; it can be named more 
appropriately ('infrastructure/', 'internal/', 'build-tools/'). We also don't 
have to publish it as an artifact.
   



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683446509


   > a318310 Made missing doclet a regular project. This also means all the 
checks are applied to it (forbidden APIs, etc.).
   
   I was so happy that `lucene/tools` was gone. Why can't we keep it in 
buildSrc and just enable forbiddenapis and other checks there?



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] [Comment Edited] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187293#comment-17187293
 ] 

Uwe Schindler edited comment on LUCENE-9215 at 8/30/20, 5:16 PM:
-

The good thing with this error is: It informs us indirectly about "dead" code, 
e.g., when somebody removes an abstract or interface method implemented by 
certain classes. When {{@Override}} is enforced, it is there from beginning. 
After abstract/interface method removal it causes error.


was (Author: thetaphi):
The good thing with this error is: It informs us about "dead" code, e.g., when 
somebody removes an abstract or interface method implemented by certain classes.

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucen

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187293#comment-17187293
 ] 

Uwe Schindler commented on LUCENE-9215:
---

The good thing with this error is: It informs us about "dead" code, e.g., when 
somebody removes an abstract or interface method implemented by certain classes.

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
>  e

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Uwe Schindler (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187292#comment-17187292
 ] 

Uwe Schindler commented on LUCENE-9215:
---

Hi,

bq. The overriden method issue can be solved without checking for an 
annotation, actually. I added a quick-and-dirty example in overrides.patch. 
Don't know if it makes sense, just wanted to point out the fact. 

I tend to open a separate issue to make the ECJ linter enforce {{@Override}}. 
Thats actually 2 lines to add to the ECJ (and also Eclipse) config:
{code}
org.eclipse.jdt.core.compiler.problem.missingOverrideAnnotation=error
org.eclipse.jdt.core.compiler.problem.missingOverrideAnnotationForInterfaceMethodImplementation=enabled
{code}

Actually this causes >250 errors in my Eclipse IDE, so it's a separate issue.

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285

[jira] [Commented] (SOLR-14540) Ref Guide: Document how-to for Block Join Facets via Query DSL

[Mikhail Khludnev (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187273#comment-17187273
 ] 

Mikhail Khludnev commented on SOLR-14540:
-

https://github.com/apache/lucene-solr/pull/1805 edits are appreciated

> Ref Guide: Document how-to for Block Join Facets via Query DSL
> --
>
> Key: SOLR-14540
> URL: https://issues.apache.org/jira/browse/SOLR-14540
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Priority: Major
> Fix For: 8.7
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr has an old good feature 
> https://lucene.apache.org/solr/guide/8_5/faceting.html#tagging-and-excluding-filters.
>  I'd like to document similar solution/snippet for 
> https://lucene.apache.org/solr/guide/8_5/json-faceting-domain-changes.html#block-join-domain-changes
>  in Query DSL. This solution combines several elements, so it's not clear 
> where to put it. Does it deserve separate page or just a paragraph somewhere? 
> Snippet is already 
> [there|https://issues.apache.org/jira/browse/SOLR-14419?focusedCommentId=17112869&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17112869]
>  it just needs some tweaks.  



--
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] mkhludnev opened a new pull request #1805: SOLR-14540: example of drill sideway block join facets

[GitBox]

mkhludnev opened a new pull request #1805:
URL: https://github.com/apache/lucene-solr/pull/1805


   Contributing example of block join drill-seideway facets to Ref Guide



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] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Dawid Weiss (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187272#comment-17187272
 ] 

Dawid Weiss commented on LUCENE-9215:
-

The overriden method issue can be solved without checking for an annotation, 
actually. I added a quick-and-dirty example in [^overrides.patch]. Don't know 
if it makes sense, just wanted to point out the fact. :)

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src

[jira] [Updated] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Dawid Weiss (Jira)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated LUCENE-9215:

Attachment: overrides.patch

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch, overrides.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
>  error - NoDoc (class): javadocs are missing
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':lucene:core:javadoc'.
> > Javadoc generation failed. G

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Dawid Weiss (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187271#comment-17187271
 ] 

Dawid Weiss commented on LUCENE-9215:
-

Done. The move has an upside in that all regular checks are applied to the 
doclet project as well (the linter complained about fall-through case, for 
example).

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
>  error - NoDoc (class)

[jira] [Commented] (SOLR-14794) Pass global cloud configuration to Collection API command execution

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187266#comment-17187266
 ] 

ASF subversion and git services commented on SOLR-14794:


Commit a3b3ba10e34b3401e7a93c1b69889df4feb6430b in lucene-solr's branch 
refs/heads/LUCENE-9215 from Ilan Ginzburg
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a3b3ba1 ]

SOLR-14794: pass configuration to Collection API commands (#1801)

Pass CloudConfig instance representing the solrcloud section of solr.xml 
configuration from Overseer to the Collection and Config Set API commands it 
executes.

> 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-9215) replace checkJavaDocs.py with doclet

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187270#comment-17187270
 ] 

ASF subversion and git services commented on LUCENE-9215:
-

Commit 8c94f5bc661ca889b94353d2f7dac94921d3baae in lucene-solr's branch 
refs/heads/LUCENE-9215 from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8c94f5b ]

Merge branch 'LUCENE-9215' of 
https://git-wip-us.apache.org/repos/asf/lucene-solr into LUCENE-9215


> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - License

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187269#comment-17187269
 ] 

ASF subversion and git services commented on LUCENE-9215:
-

Commit 8c94f5bc661ca889b94353d2f7dac94921d3baae in lucene-solr's branch 
refs/heads/LUCENE-9215 from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8c94f5b ]

Merge branch 'LUCENE-9215' of 
https://git-wip-us.apache.org/repos/asf/lucene-solr into LUCENE-9215


> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - License

[jira] [Commented] (LUCENE-9435) Clean up ant compatability remnants in Gradle build

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187267#comment-17187267
 ] 

ASF subversion and git services commented on LUCENE-9435:
-

Commit def82ab5560023ed1b00bd735596029471e81dad in lucene-solr's branch 
refs/heads/LUCENE-9215 from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=def82ab ]

LUCENE-9435: Clean up ant compatability remnants in Gradle build

* Removing ant-only unused tasks.
* Correct message in TestVersion.java
* Remove unused file.
* Removing forbidden API rules for ant.
* Remove 'resolve' emulation.
* Move ecj-lint to task-definition-relative folder.
* Remove 'packaging' specification. It'll have to wait until proper new 
packaging is implemented for Solr distribution.
* Move render-javadoc tasks's files to task-relative location.
* Moved security manager policies and default JDK logging file to gradle's task 
relative locations.
* Removing obsolete ant tools. Moving check source patterns under gradle's 
folder.
* Correct paths.
* Correct property name in task selector.

> Clean up ant compatability remnants in Gradle build
> ---
>
> Key: LUCENE-9435
> URL: https://issues.apache.org/jira/browse/LUCENE-9435
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Erick Erickson
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0)
>
>
> As per Dawid Weiss' comments in LUCENE-9433, there will be some cleanup after 
> the initial work is done.
> Assigning it to myself, to track. [~dawid.weiss]  please don't hesitate to 
> reassign if you want.



--
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-9474) Change Jenkins jobs to use Gradle for trunk

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187268#comment-17187268
 ] 

ASF subversion and git services commented on LUCENE-9474:
-

Commit d847f402373048535ca4bcd9f390f91ab9ac7a52 in lucene-solr's branch 
refs/heads/LUCENE-9215 from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d847f40 ]

LUCENE-9474: make externalTool a function and add a build-stopping message on 
Windows for snowball generator.


> Change Jenkins jobs to use Gradle for trunk
> ---
>
> Key: LUCENE-9474
> URL: https://issues.apache.org/jira/browse/LUCENE-9474
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/build
>Reporter: Erick Erickson
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> I rushed the gate and pushed LUCENE-9433 without coordinating, my apologies 
> for the confusion.
> Meanwhile, Uwe has disabled Jenkins jobs for the weekend and we'll fix this 
> up Real Soon Now.



--
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-9215) replace checkJavaDocs.py with doclet

[Dawid Weiss (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187262#comment-17187262
 ] 

Dawid Weiss commented on LUCENE-9215:
-

bq. i already hit the solr issue, i just solved it differently

Ha. I didn't even know that allprojects returns sub-hierarchy with respect to 
each project. Very elegant.

I'm on to move the doclet out from buildSrc then.

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Robert Muir (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187261#comment-17187261
 ] 

Robert Muir commented on LUCENE-9215:
-

OK [~dweiss] I'm all done now, all yours. Thanks for the help already!

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
>  error - NoDoc (class): javadocs are missing
> FAILURE: Build failed with an exception.
> * What went wrong:
> Ex

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187260#comment-17187260
 ] 

ASF subversion and git services commented on LUCENE-9215:
-

Commit e2134bd84a657e365893b7c63ccec4ddd0658fab in lucene-solr's branch 
refs/heads/LUCENE-9215 from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e2134bd ]

LUCENE-9215: add missing return true here... apparently it must not be checked 
by the doclet framework?


> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - Li

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187258#comment-17187258
 ] 

ASF subversion and git services commented on LUCENE-9215:
-

Commit 2c365f15768af6f4b0835344117ea3e25e054892 in lucene-solr's branch 
refs/heads/LUCENE-9215 from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2c365f1 ]

LUCENE-9215: more extensive javadocs checks by default

Add "parameter" which, in addition to the checks done by "method",
validates that there is an @param tag for each formal parameter of a
method/constructor.

This is a good win for an API, documenting the parameters in this way
plugs in nicely into IDEs and users can just hover over things to pop up
precisely what they need to see.

Some modules only require just a few fixes to lock this in, so we should
fix the easy wins at least (I fixed lucene/memory since it literally
only had ONE problem).


> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (clas

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Robert Muir (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187256#comment-17187256
 ] 

Robert Muir commented on LUCENE-9215:
-

I'm merging one more time (i already hit the solr issue, i just solved it 
differently) and then i'm done for a break :)

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
>  error - NoDoc (class): javadocs are missing
> FAILURE: Build f

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Dawid Weiss (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187253#comment-17187253
 ] 

Dawid Weiss commented on LUCENE-9215:
-

One more thing - the doclet currently sits in buildSrc so any change you make 
to it will invalidate all caches, etc. I'd move it into a separate regular 
project - then it is just compiled upon demand, like anything else (it also 
makes classpath references cleaner than it currently is). Give me a heads up 
when you're up for a coffee break and I'll do it (will require moving things 
around so I don't want to commit it without permission).

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missi

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Dawid Weiss (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187252#comment-17187252
 ] 

Dawid Weiss commented on LUCENE-9215:
-

I did overlook the setting in Solr's top-build file. Corrected it now.

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
>  error - NoDoc (class): javadocs are missing
> FAILURE: Build failed with an exception.
> * What went wrong:
> Ex

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Dawid Weiss (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187249#comment-17187249
 ] 

Dawid Weiss commented on LUCENE-9215:
-

Ah, darn. Sorry. It should be trivial to merge - I literally copied those ext 
snippets from each project. I see now that solrj javadoc is failing for me - 
maybe I broke something. Looking into it.

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/No

[jira] [Commented] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Robert Muir (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187247#comment-17187247
 ] 

Robert Muir commented on LUCENE-9215:
-

No worries, I will merge my changes with your work real quick and push the 
result.

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
>  error - NoDoc (class): javadocs are missing
> FAILURE: Build failed with an exception.
> * What wen

[GitHub] [lucene-solr] murblanc edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683433584


   > Here is an example of how to have strong typing for each atribute without 
creating so many different interfaces
   
   It's easy to have a single `PropertyValue` interface with all possible 
getter methods and have all but one return an empty optional. I don't see how 
that's better. [Edit: this is not exactly what you suggested though]
   
   Also I don't want to assume the plugin code knows which node a request 
should be sent to (i.e. passing the node to `onNode()`). It does know the node 
for most requests but not all. When requesting data about a given shard or 
replica for example (say number of docs, or index size), it is not the role of 
the plugin to find out which node that replica is on to route the request 
there. I prefer the behind the scenes implementation to do that.
   
   [Edit: also, a single fetch call from plugin to fetch all data on all nodes 
rather than node by node allows request optimization on the implementation 
side. The most obvious example is using multiple concurrent messages to the 
different nodes (multithreading or in any other way). If the plugin requests 
data node by node, it's either sequential or forces the plugin to implement the 
concurrency mechanism itself, making it more complicated.
   There are even more ambitious optimizations that can be made on the 
implementation side if we get all the data to distribute right away, by 
implementing for example a hierarchical distribution, to reduce the number of 
messages that have to cross Availability Zones.]



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] murblanc edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683434613


   > So, I have two main problems with this PR
   
   I consider this progress 😃 
   
   > 1. Using `solr.xml`
   
   There's no other place to set default config (not hard code!) for which 
placement plugin to use (as well as configuration parameters for that plugin). 
`solr.xml` is such a place, is used in that way for other values so makes 
perfectly sense here. Previous Autoscaling framework used `solr.xml` for config 
(for autoscaling trigger). It did not use it for the preferences and policy 
because these were collection specific, but you suggested placement plugins be 
a cluster level config so I followed that route instead.
   
   > 2. having 2 interfaces for each property
   
   Untrue. There's only one interface, for the value. Keys all share the same 
interface.
   
   



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] (LUCENE-9215) replace checkJavaDocs.py with doclet

[Dawid Weiss (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187242#comment-17187242
 ] 

Dawid Weiss commented on LUCENE-9215:
-

[~rcmuir] moved stuff around a bit, hope you're having a breakfast or 
something. 

> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/NoDoc.java:19:
>  error - NoDoc (class): javadocs are missing
> FAILURE: Build failed with an exception.
> * What went

[GitHub] [lucene-solr] murblanc edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683433584


   > Here is an example of how to have strong typing for each atribute without 
creating so many different interfaces
   
   It's easy to have a single `PropertyValue` interface with all possible 
getter methods and have all but one return an empty optional. I don't see how 
that's better.
   
   Also I don't want to assume the plugin code knows which node a request 
should be sent to (i.e. passing the node to `onNode()`). It does know the node 
for most requests but not all. When requesting data about a given shard or 
replica for example (say number of docs, or index size), it is not the role of 
the plugin to find out which node that replica is on to route the request 
there. I prefer the behind the scenes implementation to do that.
   
   [Edit: also, a single fetch call from plugin to fetch all data on all nodes 
rather than node by node allows request optimization on the implementation 
side. The most obvious example is using multiple concurrent messages to the 
different nodes (multithreading or in any other way). If the plugin requests 
data node by node, it's either sequential or forces the plugin to implement the 
concurrency mechanism itself, making it more complicated.
   There are even more ambitious optimizations that can be made on the 
implementation side if we get all the data to distribute right away, by 
implementing for example a hierarchical distribution, to reduce the number of 
messages that have to cross Availability Zones.]



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] murblanc edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683433584


   > Here is an example of how to have strong typing for each atribute without 
creating so many different interfaces
   
   It's easy to have a single `PropertyValue` interface with all possible 
getter methods and have all but one return an empty optional. I don't see how 
that's better.
   
   Also I don't want to assume the plugin code knows which node a request 
should be sent to (i.e. passing the node to `onNode()`). It does know the node 
for most requests but not all. When requesting data about a given shard or 
replica for example (say number of docs, or index size), it is not the role of 
the plugin to find out which node that replica is on to route the request 
there. I prefer the behind the scenes implementation to do that.
   
   [Edit: also, a single fetch call from plugin to fetch all data on all nodes 
rather than node by node allows request optimization on the implementation 
side. The most obvious example is using multiple concurrent messages to the 
different nodes (multithreading or in any other way). If the plugin requests 
data node by node, it's either sequential or forces the plugin to implement the 
concurrency mechanism itself, making it more complicated.
   There are even more ambitious optimizations that can be made on the 
implementation side if we get all the data to distribute right away, by 
implementing for example a hierarchical distribution, to reduce for example the 
number messages of messages that have to cross Availability Zones.]



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] murblanc edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683433584


   > Here is an example of how to have strong typing for each atribute without 
creating so many different interfaces
   
   It's easy to have a single `PropertyValue` interface with all possible 
getter methods and have all but one return an empty optional. I don't see how 
that's better.
   
   Also I don't want to assume the plugin code knows which node a request 
should be sent to (i.e. passing the node to `onNode()`). It does know the node 
for most requests but not all. When requesting data about a given shard or 
replica for example (say number of docs, or index size), it is not the role of 
the plugin to find out which node that replica is on to route the request 
there. I prefer the behind the scenes implementation to do that.
   
   [Edit: also, a single fetch call from plugin to fetch all data on all nodes 
rather than node by node allows request optimization on the implementation side 
with the most obvious example is using multiple concurrent messages to the 
different nodes (multithreading or in any other way). If the plugin requests 
data node by node, it's either sequential or forces the plugin to implement the 
concurrency mechanism itself, making it more complicated.
   There are even more ambitious optimizations that can be made on the 
implementation side if we get all the data to distribute right away, bu 
implementing for example a hierarchical distribution, to reduce for example the 
number messages of messages that have to cross Availability Zones.]



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] (LUCENE-9456) Stored fields should store the number of chunks in the meta file

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187240#comment-17187240
 ] 

ASF subversion and git services commented on LUCENE-9456:
-

Commit a04f69147e8cc6fdd8a27c9763a509e6b68b1c1f in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a04f691 ]

LUCENE-9456: fix DirectUpdateHandlerTest#testPrepareCommit (#1803)

Check for specific files being present or not or changing.  Don't make 
assumptions about file count.

(cherry picked from commit 06903a40eefa619d0746d2351da6ce79d049b3b3)


> Stored fields should store the number of chunks in the meta file
> 
>
> Key: LUCENE-9456
> URL: https://issues.apache.org/jira/browse/LUCENE-9456
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.7
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently stored fields record numChunks/numDirtyChunks at the very end of 
> the data file. They should migrate to the meta file instead, so that they 
> would be validated when opening the index (meta files get their checksum 
> validated entirely, data files don't).



--
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-9456) Stored fields should store the number of chunks in the meta file

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187239#comment-17187239
 ] 

ASF subversion and git services commented on LUCENE-9456:
-

Commit 06903a40eefa619d0746d2351da6ce79d049b3b3 in lucene-solr's branch 
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=06903a4 ]

LUCENE-9456: fix DirectUpdateHandlerTest#testPrepareCommit (#1803)

Check for specific files being present or not or changing.  Don't make 
assumptions about file count.

> Stored fields should store the number of chunks in the meta file
> 
>
> Key: LUCENE-9456
> URL: https://issues.apache.org/jira/browse/LUCENE-9456
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.7
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently stored fields record numChunks/numDirtyChunks at the very end of 
> the data file. They should migrate to the meta file instead, so that they 
> would be validated when opening the index (meta files get their checksum 
> validated entirely, data files don't).



--
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] dsmiley merged pull request #1803: LUCENE-9456: fix DirectUpdateHandlerTest#testPrepareCommit

[GitBox]

dsmiley merged pull request #1803:
URL: https://github.com/apache/lucene-solr/pull/1803


   



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] murblanc commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683434613


   > So, I have two main problems with this PR
   
   I consider this progress 😃 
   
   > 1. Using `solr.xml`
   
   There's no other place to set default config (not hard code!) for which 
placement plugin to use. `solr.xml` is such a place, is used in that way for 
other values so makes perfectly sense here. Previous Autoscaling framework used 
`solr.xml` for config (for autoscaling trigger). It did not use it for the 
preferences and policy because these were collection specific, but you 
suggested placement plugins be a cluster level config so I followed that route 
instead.
   
   > 2. having 2 interfaces for each property
   
   Untrue. There's only one interface, for the value. Keys all share the same 
interface.
   
   



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] murblanc commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

murblanc commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683433584


   > Here is an example of how to have strong typing for each atribute without 
creating so many different interfaces
   
   It's easy to have a single `PropertyValue` interface with all possible 
getter methods and have all but one return an empty optional. I don't see how 
that's better.
   
   Also I don't want to assume the plugin code knows which node a request 
should be sent to (i.e. passing the node to `onNode()`). It does know the node 
for most requests but not all. When requesting data about a given shard or 
replica for example (say number of docs, or index size), it is not the role of 
the plugin to find out which node that replica is on to route the request 
there. I prefer the behind the scenes implementation to do 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

[jira] [Commented] (LUCENE-9474) Change Jenkins jobs to use Gradle for trunk

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187236#comment-17187236
 ] 

ASF subversion and git services commented on LUCENE-9474:
-

Commit d847f402373048535ca4bcd9f390f91ab9ac7a52 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d847f40 ]

LUCENE-9474: make externalTool a function and add a build-stopping message on 
Windows for snowball generator.


> Change Jenkins jobs to use Gradle for trunk
> ---
>
> Key: LUCENE-9474
> URL: https://issues.apache.org/jira/browse/LUCENE-9474
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/build
>Reporter: Erick Erickson
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> I rushed the gate and pushed LUCENE-9433 without coordinating, my apologies 
> for the confusion.
> Meanwhile, Uwe has disabled Jenkins jobs for the weekend and we'll fix this 
> up Real Soon Now.



--
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-13652) Remove update from initParams in example solrconfig files that only mention "df"

[Alexandre Rafalovitch (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187235#comment-17187235
 ] 

Alexandre Rafalovitch commented on SOLR-13652:
--

I think this is a great discussion. And maybe it needs to be bigger. We never 
really reached even semi-consensus on learning schema vs. production schema (or 
solrconfig.xml). In fact, from Jira review, I see people complaining that we 
did completely opposite and ended up in a local minimum...

What would a bigger discussion look like? Another SIP?

> Remove update from initParams in example solrconfig files that only mention 
> "df"
> 
>
> Key: SOLR-13652
> URL: https://issues.apache.org/jira/browse/SOLR-13652
> Project: Solr
>  Issue Type: Improvement
>  Components: examples
>Reporter: Erick Erickson
>Priority: Minor
>  Labels: easyfix, newbie
>
> At least some of the solrconfig files we ship have this entry:
>  path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse,update">
>     
>   text
>     
>   
>  
> which has lead at least one user to wonder if there's some kind of automatic 
> way to have the df field populated for updates. I don't even know how you'd 
> send an update that didn't have a specific field. We should remove the 
> "update/**".



--
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-14798) Config API: indexConfig output includes all defaults

[Alexandre Rafalovitch (Jira)]

Alexandre Rafalovitch created SOLR-14798:


 Summary: Config API: indexConfig output includes all defaults
 Key: SOLR-14798
 URL: https://issues.apache.org/jira/browse/SOLR-14798
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: config-api
Reporter: Alexandre Rafalovitch


In XML (without comments):
{code:java}

  ${solr.lock.type:native}

 {code}
In config api output:
{code:java}
"indexConfig":{
  "useCompoundFile":false,
  "maxBufferedDocs":-1,
  "ramBufferSizeMB":100.0,
  "ramPerThreadHardLimitMB":-1,
  "maxCommitMergeWaitTime":-1,
  "writeLockTimeout":-1,
  "lockType":"native",
  "infoStreamEnabled":false,
  "metrics":{
{code}



--
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] (SOLR-14783) Remove DIH from 9.0

[Alexandre Rafalovitch (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandre Rafalovitch updated SOLR-14783:
-
Description: 
Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it can 
be removed in next major version (9).

Future work on it can continue happening in the external package: 
https://github.com/rohitbemax/dataimporthandler

  was:Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it 
can be removed in next major version (9)


> Remove DIH from 9.0
> ---
>
> Key: SOLR-14783
> URL: https://issues.apache.org/jira/browse/SOLR-14783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Affects Versions: master (9.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it can 
> be removed in next major version (9).
> Future work on it can continue happening in the external package: 
> https://github.com/rohitbemax/dataimporthandler



--
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-9215) replace checkJavaDocs.py with doclet

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187216#comment-17187216
 ] 

ASF subversion and git services commented on LUCENE-9215:
-

Commit b85369090e2a4f2116c639e02070ae4d085404cc in lucene-solr's branch 
refs/heads/LUCENE-9215 from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b853690 ]

LUCENE-9215: add more fixed packages to lucene/core and add some comments.

The previous python tool did recursive file traversal, so the list of
packages was recursive.

In our case we do exact matching on the package name.
Add the subpackages too, since they have full documentation and are already 
fixed.

Also add a few more comments to the linter explaining the hairy parts.


> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs

[GitHub] [lucene-solr] noblepaul opened a new pull request #1804: SOLR-14151: Bbug fixes

[GitBox]

noblepaul opened a new pull request #1804:
URL: https://github.com/apache/lucene-solr/pull/1804


   



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] (LUCENE-9215) replace checkJavaDocs.py with doclet

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187214#comment-17187214
 ] 

ASF subversion and git services commented on LUCENE-9215:
-

Commit 87a693f4e3c0f0c37c38c5646e5af6a5d5ebbeb5 in lucene-solr's branch 
refs/heads/LUCENE-9215 from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=87a693f ]

LUCENE-9215: add missing quote attribution :)


> replace checkJavaDocs.py with doclet
> 
>
> Key: LUCENE-9215
> URL: https://issues.apache.org/jira/browse/LUCENE-9215
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9215_prototype.patch
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The current checker runs regular expressions against html, and it breaks when 
> newer java change html output. This is not particularly fun to fix: see 
> LUCENE-9213
> Java releases often now, and when i compared generated html of a simple class 
> across 11,12,13 it surprised me how much changes. So I think we want to avoid 
> parsing their HTML.
> Javadoc {{Xdoclint}} feature has a "missing checker": but it is black/white. 
> Either everything is fully documented or its not. And while you can 
> enable/disable doclint checks per-package, this also seems black/white 
> (either all checks or no checks at all).
> On the other hand the python checker is able to check per-package at 
> different granularities (package, class, method). It makes it possible to 
> iteratively improve the situation.
> With doclet api we could implement checks in pure java, for example to match 
> checkJavaDocs.py logic:
> {code}
>   private void checkComment(Element element) {
> var tree = docTrees.getDocCommentTree(element);
> if (tree == null) {
>   error(element, "javadocs are missing");
> } else {
>   var normalized = tree.getFirstSentence().get(0).toString()
>.replace('\u00A0', ' ')
>.trim()
>.toLowerCase(Locale.ROOT);
>   if (normalized.isEmpty()) {
> error(element, "blank javadoc comment");
>   } else if (normalized.startsWith("licensed to the apache software 
> foundation") ||
>  normalized.startsWith("copyright 2004 the apache software 
> foundation")) {
> error(element, "comment is really a license");
>   }
> }
> {code}
> If there are problems then they just appear as errors from the output of 
> {{javadoc}} like usual:
> {noformat}
> javadoc: error - org.apache.lucene.nodoc (package): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNearQuery.java:190:
>  error - SpanNearWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanContainingQuery.java:54:
>  error - SpanContainingWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanWithinQuery.java:55:
>  error - SpanWithinWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanTermQuery.java:94:
>  error - SpanTermWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanNotQuery.java:109:
>  error - SpanNotWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanOrQuery.java:139:
>  error - SpanOrWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/spans/SpanPositionCheckQuery.java:77:
>  error - SpanPositionCheckWeight (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:61:
>  error - Collectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/search/MultiCollectorManager.java:89:
>  error - LeafCollectors (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:353:
>  error - PagedBytesDataOutput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/util/PagedBytes.java:285:
>  error - PagedBytesDataInput (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/EmptyDoc.java:22:
>  error - EmptyDoc (class): javadocs are missing
> /home/rmuir/workspace/lucene-solr/lucene/core/src/java/org/apache/lucene/nodoc/LicenseDoc.java:36:
>  error - LicenseDoc (class): comment is really a license
> /home/rmuir

[GitHub] [lucene-solr] noblepaul edited a comment on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

noblepaul edited a comment on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683420028


   Here is an example of how to have strong typing for each atribute without 
creating  so many different interfaces
   
   `public interface PropertyFetcher {`
 `PropertyFetcher onNode(String nodeName);`
` PropertyFetcher withCoreCount();`
 `PropertyFetcher withSystemProperty(String name);`
 
 `PropertyValues fetchValues();`
 
` interface PropertyValues {`
   `Optional coreCount();`
   `Optional systemProperty(String propertyName);}}`
   `



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] noblepaul commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

noblepaul commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683420148


   So, I have two main  problems with this PR
   
   1. Using `solr.xml` 
   2. having 2 interfaces for each property



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] noblepaul commented on pull request #1684: SOLR-14613: strongly typed initial proposal for placement plugin interface

[GitBox]

noblepaul commented on pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#issuecomment-683420028


   Here is an example of how to have strong typing for each atribute without 
creating  so many different interfaces
   
   `public interface PropertyFetcher {`
 `PropertyFetcher onNode();`
` PropertyFetcher withCoreCount();`
 `PropertyFetcher withSystemProperty(String name);`
 
 `PropertyValues fetchValues();`
 
` interface PropertyValues {`
   `Optional coreCount();`
   `Optional systemProperty(String propertyName);}}`
   `



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] rmuir commented on a change in pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

rmuir commented on a change in pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#discussion_r479766765



##
File path: buildSrc/src/main/java/org/apache/lucene/gradle/MissingDoclet.java
##
@@ -0,0 +1,331 @@
+/*
+ * 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.gradle;
+
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Locale;
+import java.util.Set;
+
+import javax.lang.model.element.Element;
+import javax.lang.model.element.ElementKind;
+import javax.lang.model.element.ModuleElement;
+import javax.lang.model.util.Elements;
+import javax.tools.Diagnostic;
+
+import com.sun.source.util.DocTrees;
+
+import jdk.javadoc.doclet.Doclet;
+import jdk.javadoc.doclet.DocletEnvironment;
+import jdk.javadoc.doclet.Reporter;
+import jdk.javadoc.doclet.StandardDoclet;
+
+/**
+ * Checks for missing javadocs, where missing also means "only whitespace" or 
"license header".
+ * Has option --missing-level (package, class, method) so that we can improve 
over time.
+ * Has option --missing-ignore to ignore individual elements (such as split 
packages).
+ * Has option --missing-method to apply "method" level to selected packages 
(fix one at a time).
+ */
+public class MissingDoclet extends StandardDoclet {
+  private static final int PACKAGE = 0;
+  private static final int CLASS = 1;
+  private static final int METHOD = 2;
+  int level = METHOD;
+  Reporter reporter;
+  DocletEnvironment docEnv;
+  DocTrees docTrees;
+  Elements elementUtils;
+  Set ignored = Collections.emptySet();
+  Set methodPackages = Collections.emptySet();
+  
+  @Override
+  public Set getSupportedOptions() {
+Set options = new HashSet<>();
+options.addAll(super.getSupportedOptions());
+options.add(new Doclet.Option() {
+  @Override
+  public int getArgumentCount() {
+return 1;
+  }
+
+  @Override
+  public String getDescription() {
+return "level to enforce for missing javadocs: [package, class, 
method]";
+  }
+
+  @Override
+  public Kind getKind() {
+return Option.Kind.STANDARD;
+  }
+
+  @Override
+  public List getNames() {
+return Collections.singletonList("--missing-level");
+  }
+
+  @Override
+  public String getParameters() {
+return "level";
+  }
+
+  @Override
+  public boolean process(String option, List arguments) {
+switch(arguments.get(0)) {
+  case "package":
+level = PACKAGE;
+return true;
+  case "class":
+level = CLASS;
+return true;
+  case "method":
+level = METHOD;
+return true;
+  default:
+return false;
+}
+  }
+});
+options.add(new Doclet.Option() {
+  @Override
+  public int getArgumentCount() {
+return 1;
+  }
+
+  @Override
+  public String getDescription() {
+return "comma separated list of element names to ignore (e.g. as a 
workaround for split packages)";
+  }
+
+  @Override
+  public Kind getKind() {
+return Option.Kind.STANDARD;
+  }
+
+  @Override
+  public List getNames() {
+return Collections.singletonList("--missing-ignore");
+  }
+
+  @Override
+  public String getParameters() {
+return "ignoredNames";
+  }
+
+  @Override
+  public boolean process(String option, List arguments) {
+ignored = new HashSet<>(Arrays.asList(arguments.get(0).split(",")));
+return true;
+  }
+});
+options.add(new Doclet.Option() {
+  @Override
+  public int getArgumentCount() {
+return 1;
+  }
+
+  @Override
+  public String getDescription() {
+return "comma separated list of packages to check at 'method' level";
+  }
+
+  @Override
+  public Kind getKind() {
+return Option.Kind.STANDARD;
+  }
+
+  @Override
+  public List getNames() {
+return Collections.singletonList("--missing-method");
+  }
+
+  @Override
+  public String getParameters() {
+return "pac

[GitHub] [lucene-solr] rmuir commented on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

rmuir commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683413964


   Thanks @dweiss @uschindler @mocobeta  please, make any changes if you have 
the time and motiviation. I agree with the suggestions: plumbing the correct 
inputs sounds great to make it easier to fix the problems (no need to run 
clean). As far as how it is organized or how problems are fixed, it doesn't 
really matter to me, I was just trying to get things working. 
   
   It is true i took a somewhat risky approach to make some things private. If 
someone really wants a class to be public they could at least have a one-liner 
describing what it does. So alternatively these classes could stay public but 
get some documentation (it means doing real work though)
   
   I added the missing `@Override`s because I use the presence of the 
annotation as a proxy to determine that a method is overridden (and that java 
will be copied). Maybe it is not theoretically the best way, but it was simple 
and there was a lot to fix here. I know at least the ECJ compiler has the 
option to enforce that `@Override` is always there, maybe we should turn  that 
on too separately.



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] (LUCENE-9490) gradlew checkMissingDocsDefault fails on JDK 15 or later

[Tomoko Uchida (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187195#comment-17187195
 ] 

Tomoko Uchida commented on LUCENE-9490:
---

bq. Robert made such great progress with doclet parser that indeed seems like 
we should focus on getting that in.

Yes, sure. That my comment was posted before seeing the PR, we no longer need 
patches to the python linter.

> gradlew checkMissingDocsDefault fails on JDK 15 or later
> 
>
> Key: LUCENE-9490
> URL: https://issues.apache.org/jira/browse/LUCENE-9490
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Dawid Weiss
>Priority: Major
>  Labels: Java15
> Attachments: LUCENE-9490.patch, screen-[1].png
>
>
> All Policeman Jenkins Jobs fail on the EA build with Java 15. Reason is that 
> the task {{checkMissingDocsDefault}} fails due to "missing documentation":
> {noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script 
> '/home/jenkins/workspace/Lucene-Solr-master-Linux/gradle/validation/missing-docs-check.gradle'
>  line: 105
> * What went wrong:
> Execution failed for task ':lucene:classification:checkMissingDocsDefault'.
> > Javadoc verification failed:
>   Traceback (most recent call last):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 388, in 
>   if checkPackageSummaries(sys.argv[1], level):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 368, in checkPackageSummaries
>   if checkClassSummaries(fullPath):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 227, in checkClassSummaries
>   raise RuntimeError('failed to locate javadoc item in %s, line %d? last 
> line: %s' % (fullPath, lineCount, line.rstrip()))
>   RuntimeError: failed to locate javadoc item in 
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/classification/build/docs/javadoc/org/apache/lucene/classification/ClassificationResult.html,
>  line 135? last line: 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}
> Interestingly, it doe snot fail on all subprojects. It looks like JDK15 
> changed the HTML output and so the checks are failing.
> With the Ant build this was not a problem, as we disabled this task (and all 
> other documentation-lint tasks), if running with an unsupported JDK version. 
> It's very har to rely on HTML output, as this can change on every JDK version.
> We have 2 options:
> - Maybe fix some regular expression in the python script (sorry I have no 
> idea on python and what's the problem)
> - Disable the python-linter tasks as we did in Ant, when the java version (of 
> RUNTIME_JAVA_HOME) is outside our expectations!
> My personal opinion is to handle this in same way like Ant: Disable the 
> documentation-linter for any RUNTIME_JAVA_HOME version later than our 
> supported one. Or maybe disable it always when we use an alternative JDK? 
> That's easiest to check when bulding task dependencies in Gradle, IMHO, 
> whenever an alternate Java Home is given. If the alternative JVM is the same 
> as Gradle's it would be kept enabled anyways, so the ideal place for this 
> would be here:
> https://github.com/apache/lucene-solr/blob/master/gradle/testing/alternative-jdk-support.gradle#L52-L71
> Just add another {{tasks.withType()}}. and set {{task.enabled = false}}.
> [~dawid.weiss], [~tomoko]: Any ideas or recommendation?



--
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-9475) Enhance the Gradle build as necessary after removing Ant support

[Dawid Weiss (Jira)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated LUCENE-9475:

Description: 
Once the bulk of the Ant build system is removed, stuff will come bubbling up 
out of the cracks, especially as we try the first 9.0 release which will be 
Gradle only. Here we list some of the areas we'll have to be aware of. Please 
add as you see fit. Assigning to myself to track, but I certainly don't want 
hog all the fun.
 * Remove Maven support and replace with "The Gradle Way" of doing Maven. See 
LUCENE-9077 (Dawid)

 * 
 ** Remove all of dev-tools/maven?
 ** Other dev-tools files no longer used, check if any Gradle build file 
references and remove if not.
 * -Move Jenkins over to use Gradle only-
 * -Verify reference guide build works under Gradle-
 * Smoke tester
 * Remove anything having to to with Clover (obsolete as of Java 11)
 * -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} -
 * Remove obsolete files in root dirs of lucene and solr (like 
version.properties, now integrated into gradle)
 * Remove Maven build files (obsolete with Gradle)
 * Hoss's test rollups?
 * Enable javadocs after ant stops being used (LUCENE-9441)
 * fix some relative links in javadocs which contain ant module names (?)
 * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, 
and some in the README.md. This one should probably be its own JIRA since it'll 
require quite a bit of verification...
 * -Make "the best damn beasting script in the world" work with the Gradle 
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
 * Update the release documentation to reflect Gradle (LUCENE-9488)
 * Clean up anything in lucene/tools
 * Clean up Confluence, in particular any page that mentions IDEs. The "How to 
Contribute" page has several links to various bits and pieces of how to use 
IDEs, and some mention ant.

  was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up 
out of the cracks, especially as we try the first 9.0 release which will be 
Gradle only. Here we list some of the areas we'll have to be aware of. Please 
add as you see fit. Assigning to myself to track, but I certainly don't want 
hog all the fun.
 * Remove Maven support and replace with "The Gradle Way" of doing Maven. See 
LUCENE-9077 (Dawid)

 * 
 ** Remove all of dev-tools/maven?
 ** Other dev-tools files no longer used, check if any Gradle build file 
references and remove if not.
 * -Move Jenkins over to use Gradle only-
 * -Verify reference guide build works under Gradle-
 * Smoke tester
 * Remove anything having to to with Clover (obsolete as of Java 11)
 * -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} - (this is part of 
post-ant cleanup, I'll do it).
 * Remove obsolete files in root dirs of lucene and solr (like 
version.properties, now integrated into gradle)
 * Remove Maven build files (obsolete with Gradle)
 * Hoss's test rollups?
 * Enable javadocs after ant stops being used (LUCENE-9441)
 * fix some relative links in javadocs which contain ant module names (?)
 * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, 
and some in the README.md. This one should probably be its own JIRA since it'll 
require quite a bit of verification...
 * -Make "the best damn beasting script in the world" work with the Gradle 
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
 * Update the release documentation to reflect Gradle (LUCENE-9488)
 * Clean up anything in lucene/tools
 * Clean up Confluence, in particular any page that mentions IDEs. The "How to 
Contribute" page has several links to various bits and pieces of how to use 
IDEs, and some mention ant.


> Enhance the Gradle build as necessary after removing Ant support
> 
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up 
> out of the cracks, especially as we try the first 9.0 release which will be 
> Gradle only. Here we list some of the areas we'll have to be aware of. Please 
> add as you see fit. Assigning to myself to track, but I certainly don't want 
> hog all the fun.
>  * Remove Maven support and replace with "The Gradle Way" of doing Maven. See 
> LUCENE-9077 (Dawid)
>  * 
>  ** Remove all of dev-tools/maven?
>  ** Other dev-tools files no longer used, check if any Gradle build file 
> references and remove if not.
>  * -Move Jenkins over to use Gradle only-
>  * -Verify reference 

[jira] [Commented] (LUCENE-9435) Clean up ant compatability remnants in Gradle build

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187194#comment-17187194
 ] 

ASF subversion and git services commented on LUCENE-9435:
-

Commit def82ab5560023ed1b00bd735596029471e81dad in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=def82ab ]

LUCENE-9435: Clean up ant compatability remnants in Gradle build

* Removing ant-only unused tasks.
* Correct message in TestVersion.java
* Remove unused file.
* Removing forbidden API rules for ant.
* Remove 'resolve' emulation.
* Move ecj-lint to task-definition-relative folder.
* Remove 'packaging' specification. It'll have to wait until proper new 
packaging is implemented for Solr distribution.
* Move render-javadoc tasks's files to task-relative location.
* Moved security manager policies and default JDK logging file to gradle's task 
relative locations.
* Removing obsolete ant tools. Moving check source patterns under gradle's 
folder.
* Correct paths.
* Correct property name in task selector.

> Clean up ant compatability remnants in Gradle build
> ---
>
> Key: LUCENE-9435
> URL: https://issues.apache.org/jira/browse/LUCENE-9435
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Erick Erickson
>Assignee: Dawid Weiss
>Priority: Major
>
> As per Dawid Weiss' comments in LUCENE-9433, there will be some cleanup after 
> the initial work is done.
> Assigning it to myself, to track. [~dawid.weiss]  please don't hesitate to 
> reassign if you want.



--
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-9435) Clean up ant compatability remnants in Gradle build

[Dawid Weiss (Jira)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss resolved LUCENE-9435.
-
Fix Version/s: master (9.0)
   Resolution: Fixed

> Clean up ant compatability remnants in Gradle build
> ---
>
> Key: LUCENE-9435
> URL: https://issues.apache.org/jira/browse/LUCENE-9435
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Erick Erickson
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0)
>
>
> As per Dawid Weiss' comments in LUCENE-9433, there will be some cleanup after 
> the initial work is done.
> Assigning it to myself, to track. [~dawid.weiss]  please don't hesitate to 
> reassign if you want.



--
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] dweiss merged pull request #1799: Lucene 9435

[GitBox]

dweiss merged pull request #1799:
URL: https://github.com/apache/lucene-solr/pull/1799


   



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 #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on a change in pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#discussion_r479761009



##
File path: buildSrc/src/main/java/org/apache/lucene/gradle/MissingDoclet.java
##
@@ -0,0 +1,331 @@
+/*
+ * 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.gradle;
+
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Locale;
+import java.util.Set;
+
+import javax.lang.model.element.Element;
+import javax.lang.model.element.ElementKind;
+import javax.lang.model.element.ModuleElement;
+import javax.lang.model.util.Elements;
+import javax.tools.Diagnostic;
+
+import com.sun.source.util.DocTrees;
+
+import jdk.javadoc.doclet.Doclet;
+import jdk.javadoc.doclet.DocletEnvironment;
+import jdk.javadoc.doclet.Reporter;
+import jdk.javadoc.doclet.StandardDoclet;
+
+/**
+ * Checks for missing javadocs, where missing also means "only whitespace" or 
"license header".
+ * Has option --missing-level (package, class, method) so that we can improve 
over time.
+ * Has option --missing-ignore to ignore individual elements (such as split 
packages).
+ * Has option --missing-method to apply "method" level to selected packages 
(fix one at a time).
+ */
+public class MissingDoclet extends StandardDoclet {
+  private static final int PACKAGE = 0;
+  private static final int CLASS = 1;
+  private static final int METHOD = 2;
+  int level = METHOD;
+  Reporter reporter;
+  DocletEnvironment docEnv;
+  DocTrees docTrees;
+  Elements elementUtils;
+  Set ignored = Collections.emptySet();
+  Set methodPackages = Collections.emptySet();
+  
+  @Override
+  public Set getSupportedOptions() {
+Set options = new HashSet<>();
+options.addAll(super.getSupportedOptions());
+options.add(new Doclet.Option() {
+  @Override
+  public int getArgumentCount() {
+return 1;
+  }
+
+  @Override
+  public String getDescription() {
+return "level to enforce for missing javadocs: [package, class, 
method]";
+  }
+
+  @Override
+  public Kind getKind() {
+return Option.Kind.STANDARD;
+  }
+
+  @Override
+  public List getNames() {
+return Collections.singletonList("--missing-level");
+  }
+
+  @Override
+  public String getParameters() {
+return "level";
+  }
+
+  @Override
+  public boolean process(String option, List arguments) {
+switch(arguments.get(0)) {
+  case "package":
+level = PACKAGE;
+return true;
+  case "class":
+level = CLASS;
+return true;
+  case "method":
+level = METHOD;
+return true;
+  default:
+return false;
+}
+  }
+});
+options.add(new Doclet.Option() {
+  @Override
+  public int getArgumentCount() {
+return 1;
+  }
+
+  @Override
+  public String getDescription() {
+return "comma separated list of element names to ignore (e.g. as a 
workaround for split packages)";
+  }
+
+  @Override
+  public Kind getKind() {
+return Option.Kind.STANDARD;
+  }
+
+  @Override
+  public List getNames() {
+return Collections.singletonList("--missing-ignore");
+  }
+
+  @Override
+  public String getParameters() {
+return "ignoredNames";
+  }
+
+  @Override
+  public boolean process(String option, List arguments) {
+ignored = new HashSet<>(Arrays.asList(arguments.get(0).split(",")));
+return true;
+  }
+});
+options.add(new Doclet.Option() {
+  @Override
+  public int getArgumentCount() {
+return 1;
+  }
+
+  @Override
+  public String getDescription() {
+return "comma separated list of packages to check at 'method' level";
+  }
+
+  @Override
+  public Kind getKind() {
+return Option.Kind.STANDARD;
+  }
+
+  @Override
+  public List getNames() {
+return Collections.singletonList("--missing-method");
+  }
+
+  @Override
+  public String getParameters() {
+return

[jira] [Commented] (LUCENE-9490) gradlew checkMissingDocsDefault fails on JDK 15 or later

[Dawid Weiss (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187192#comment-17187192
 ] 

Dawid Weiss commented on LUCENE-9490:
-

bq. Yes I think the simplified regex is correct, but it seems to break the 
assumption for succeeding m.group(1)

Use a non-capturing group? :)

Robert made such great progress with doclet parser that indeed seems like we 
should focus on getting that in.

> gradlew checkMissingDocsDefault fails on JDK 15 or later
> 
>
> Key: LUCENE-9490
> URL: https://issues.apache.org/jira/browse/LUCENE-9490
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Dawid Weiss
>Priority: Major
>  Labels: Java15
> Attachments: LUCENE-9490.patch, screen-[1].png
>
>
> All Policeman Jenkins Jobs fail on the EA build with Java 15. Reason is that 
> the task {{checkMissingDocsDefault}} fails due to "missing documentation":
> {noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script 
> '/home/jenkins/workspace/Lucene-Solr-master-Linux/gradle/validation/missing-docs-check.gradle'
>  line: 105
> * What went wrong:
> Execution failed for task ':lucene:classification:checkMissingDocsDefault'.
> > Javadoc verification failed:
>   Traceback (most recent call last):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 388, in 
>   if checkPackageSummaries(sys.argv[1], level):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 368, in checkPackageSummaries
>   if checkClassSummaries(fullPath):
> File 
> "/home/jenkins/workspace/Lucene-Solr-master-Linux/dev-tools/scripts/checkJavaDocs.py",
>  line 227, in checkClassSummaries
>   raise RuntimeError('failed to locate javadoc item in %s, line %d? last 
> line: %s' % (fullPath, lineCount, line.rstrip()))
>   RuntimeError: failed to locate javadoc item in 
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/classification/build/docs/javadoc/org/apache/lucene/classification/ClassificationResult.html,
>  line 135? last line: 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}
> Interestingly, it doe snot fail on all subprojects. It looks like JDK15 
> changed the HTML output and so the checks are failing.
> With the Ant build this was not a problem, as we disabled this task (and all 
> other documentation-lint tasks), if running with an unsupported JDK version. 
> It's very har to rely on HTML output, as this can change on every JDK version.
> We have 2 options:
> - Maybe fix some regular expression in the python script (sorry I have no 
> idea on python and what's the problem)
> - Disable the python-linter tasks as we did in Ant, when the java version (of 
> RUNTIME_JAVA_HOME) is outside our expectations!
> My personal opinion is to handle this in same way like Ant: Disable the 
> documentation-linter for any RUNTIME_JAVA_HOME version later than our 
> supported one. Or maybe disable it always when we use an alternative JDK? 
> That's easiest to check when bulding task dependencies in Gradle, IMHO, 
> whenever an alternate Java Home is given. If the alternative JVM is the same 
> as Gradle's it would be kept enabled anyways, so the ideal place for this 
> would be here:
> https://github.com/apache/lucene-solr/blob/master/gradle/testing/alternative-jdk-support.gradle#L52-L71
> Just add another {{tasks.withType()}}. and set {{task.enabled = false}}.
> [~dawid.weiss], [~tomoko]: Any ideas or recommendation?



--
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 edited a comment on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler edited a comment on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683408276


   I agree with Dawid. At the beginning I did not like his approach to 
centralize everything, but this makes maintenance easier, as you have a better 
overview.
   The build.gradle files per module are just metadata for Maven, nothing more. 
I kinda like this now.



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

dweiss commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683410761


   Just to be clear, Robert - I can correct this, let me know if you're ok with 
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] uschindler commented on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683408548


   I would make the settings of the linter `@Input` options of the 
RenderJavadocs task, prepoulated with the project variables (like Javadocs 
URLs).



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 pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

uschindler commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683408276


   I agree with Dawid. At the beginning I did not like his approach to 
centralize everything, but this makes maintenance easier, as you have a better 
overview.
   The build.gradle files per module are just metadata for Maven, nothing more. 
I kinda link this now.



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-13652) Remove update from initParams in example solrconfig files that only mention "df"

[Erick Erickson (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187183#comment-17187183
 ] 

Erick Erickson commented on SOLR-13652:
---

Agreed. Either we need a copyField directive of everything to "text" or not 
define df at all.

Doing a copyField is inelegant. Any "serious" installation will take it out. 
Blah blah blah. It still allows you to get started without errors.

 

Pulling df out entirely will produce a pretty explicit error "no field name 
specified in query and no default specified via 'df' param" for searches like 
q=something if df isn't defined, but that;s not as helpful as getting results 
back...

> Remove update from initParams in example solrconfig files that only mention 
> "df"
> 
>
> Key: SOLR-13652
> URL: https://issues.apache.org/jira/browse/SOLR-13652
> Project: Solr
>  Issue Type: Improvement
>  Components: examples
>Reporter: Erick Erickson
>Priority: Minor
>  Labels: easyfix, newbie
>
> At least some of the solrconfig files we ship have this entry:
>  path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse,update">
>     
>   text
>     
>   
>  
> which has lead at least one user to wonder if there's some kind of automatic 
> way to have the df field populated for updates. I don't even know how you'd 
> send an update that didn't have a specific field. We should remove the 
> "update/**".



--
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-14784) Reproducible failure for DirectUpdateHandlerTest

[Erick Erickson (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187181#comment-17187181
 ] 

Erick Erickson commented on SOLR-14784:
---

Oops, didn't see you saw this I filed it as a Solr bug before tracing it 
because it was a Solr test that failed.

 

> Reproducible failure for DirectUpdateHandlerTest
> 
>
> Key: SOLR-14784
> URL: https://issues.apache.org/jira/browse/SOLR-14784
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Priority: Major
> Attachments: DirectUpdateHandlerTest-fail.txt, 
> DirectUpdateHandlerTest-success.xml
>
>
> This is rather weird. It apparently was introduced by LUCENE-9456, but that 
> seems odd. Although I do note that that push may do some different error 
> handling, perhaps Solr needs to accommodate that.
> Of course it doesn't necessarily reproduce with other seeds.
> [~jpountz] do you have any hints?
> Reproduce 100% with:
> ./gradlew :solr:core:test --tests 
> "org.apache.solr.update.DirectUpdateHandlerTest" 
> -Ptests.seed=2BE3A8682E5E346D -Ptests.multiplier=2 -Ptests.badapples=false 
> -Ptests.file.encoding=US-ASCII
>  



--
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-9456) Stored fields should store the number of chunks in the meta file

[Erick Erickson (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187180#comment-17187180
 ] 

Erick Erickson commented on LUCENE-9456:


[~dsmiley] see: SOLR-14784, [~jpountz]  is working on this too...

> Stored fields should store the number of chunks in the meta file
> 
>
> Key: LUCENE-9456
> URL: https://issues.apache.org/jira/browse/LUCENE-9456
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 8.7
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently stored fields record numChunks/numDirtyChunks at the very end of 
> the data file. They should migrate to the meta file instead, so that they 
> would be validated when opening the index (meta files get their checksum 
> validated entirely, data files don't).



--
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] dweiss commented on pull request #1802: LUCENE-9215: replace checkJavaDocs.py with doclet

[GitBox]

dweiss commented on pull request #1802:
URL: https://github.com/apache/lucene-solr/pull/1802#issuecomment-683402017


   This looks really good already! My personal preference would be to keep the 
processing options inside the render javadoc file, rather than pushing them 
down to each project's build.gradle but it can definitely wait. Other than that 
I kept wondering if this should piggyback public/private scope changes to 
classes. Those weight classes in particular - making them private will have 
side-effects for other code (that may be doing an instanceof, for example).



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-14785) Update synonyms by API and reload collection in Solr

[Gitterh (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187166#comment-17187166
 ] 

Gitterh commented on SOLR-14785:


Thank you. I've found the issue, it was that in application we also appending 
the fuzziness prefix `~1` and in this case the synonyms are not applied.

> Update synonyms by API and reload collection in Solr
> 
>
> Key: SOLR-14785
> URL: https://issues.apache.org/jira/browse/SOLR-14785
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 8.6.1
>Reporter: Gitterh
>Priority: Major
>
> I am using Solr 8.6.1, started in solrcloud mode.
> The field type is
> ```
> {
>  "add-field-type" : {
>  "name":"articleTitle",
>  "positionIncrementGap":100,
>  "multiValued":false,
>  "class":"solr.TextField",
>  "indexAnalyzer":{
>  "tokenizer":\{ "class":"solr.StandardTokenizerFactory" },
>  "filters":[
>  \{ "class":"solr.LowerCaseFilterFactory" },
>  \{ "class":"solr.ManagedStopFilterFactory", "managed":"english" },
>  \{ "class":"solr.ManagedSynonymGraphFilterFactory", "managed":"english" },
>  \{ "class":"solr.FlattenGraphFilterFactory" },
>  \{ "class":"solr.PorterStemFilterFactory" }
>  ]
>  },
>  "queryAnalyzer":{
>  "tokenizer":\{ "class":"solr.StandardTokenizerFactory" },
>  "filters":[
>  \{ "class":"solr.LowerCaseFilterFactory" },
>  \{ "class":"solr.ManagedStopFilterFactory", "managed":"english" },
>  \{ "class":"solr.ManagedSynonymGraphFilterFactory", "managed":"english" },
>  \{ "class":"solr.PorterStemFilterFactory" }
>  ]
>  }
>  }
>  }
> ```
> After I add a document
> ```
> {
>  "id": 100,
>  "articleTitle": "Best smartphone"
> } 
> ```
> I update the synonyms list by API 
> ```
> curl -X PUT -H 'Content-type:application/json' --data-binary '["iphone", 
> "smartphone"]' 
> "http://localhost:8983/solr/articles/schema/analysis/synonyms/english";
> ```
> and reload the collection by API
> ```
> http://localhost:8983/solr/admin/collections?action=RELOAD&name=articles
> ```
> However when I try to search the documents don't pop-up.
> ```
> http://localhost:8983/solr/articles/select?q=articleTitle:iphone
> ```
> No result are returned. I expected that added document will be returned.
> It works only if I first update the synonyms list and after that add the 
> document into collection.
> How to configure Solr to find the documents by synonyms if the synonyms are 
> changed after documents are created?



--
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