Repository navigation
SOLR-18463: Rename Post Tool and Stream Tool to Post Command and Stream Command - #4924
Conversation
…am Command Both were standalone tools historically and are now bin/solr subcommands, so calling them Tool alongside their own page titles and headings is no longer accurate. Left one occurrence untouched: the verbatim --help output on the Post Command page, which reflects the actual CLI text and would need a Java change, not a doc change.
|
@epugh tagging you since this is under SOLR-18459/SOLR-18463, which you filed. |
| === Start an external Apache Tika Server | ||
|
|
||
| Indexing binary files (PDF, DOCX, PPTX, etc.) with the Post Tool requires the Solr extraction module to be enabled and an external Apache Tika Server to be running. See xref:indexing-guide:indexing-with-tika.adoc#tika-server[Tika Server] for background. We will be running Tika Server using Docker. | ||
| Indexing binary files (PDF, DOCX, PPTX, etc.) with the Post Command requires the Solr extraction module to be enabled and an external Apache Tika Server to be running. See xref:indexing-guide:indexing-with-tika.adoc#tika-server[Tika Server] for background. We will be running Tika Server using Docker. |
There was a problem hiding this comment.
if this is the first time we use "Post Command" can we do seomting like "Solr CLI Post command"?
There was a problem hiding this comment.
Done — now reads "Solr CLI Post command" on first mention.
|
|
||
| Local Files with `bin/solr post`:: | ||
| If you have a local directory of files, the Post Tool (`bin/solr post`) can index a directory of files. | ||
| If you have a local directory of files, the Post Command (`bin/solr post`) can index a directory of files. |
There was a problem hiding this comment.
command doesn't need to be capilized i don't htink?
There was a problem hiding this comment.
Done — lowercased.
| @@ -1,4 +1,4 @@ | |||
| = Post Tool | |||
| = Post Command | |||
There was a problem hiding this comment.
Maybe Solr CLI Post Command? I think we should just keep post-tool for SEO... Though there is a redirect capablity in Ref Guide which means we could rename this somethin glike post-command.adoc??
There was a problem hiding this comment.
Renamed to post-command.adoc with :page-aliases: post-tool.adoc, so post-tool.html still resolves — it redirects to the new page.
| // under the License. | ||
|
|
||
| The Stream tool allows you to run a xref:streaming-expressions.adoc[] in Solr and see the results from the command line. | ||
| The Stream Command allows you to run a xref:streaming-expressions.adoc[] in Solr and see the results from the command line. |
There was a problem hiding this comment.
Done — lowercased.
| @@ -1,4 +1,4 @@ | |||
| = Stream Tool | |||
| = Stream Command | |||
There was a problem hiding this comment.
Same "Solr CLI Stream Command"
There was a problem hiding this comment.
Done — title is now "Solr CLI Stream Command".
epugh
left a comment
There was a problem hiding this comment.
Progress, I left feedback!
Rename post-tool.adoc/stream-tool.adoc to post-command.adoc/stream-command.adoc with page-aliases so the old SEO'd URLs keep resolving (via Antora's static redirect facility, confirmed by inspecting the built HTML). Prefix the page titles and each page's first mention with "Solr CLI" per review, and drop the capital "C" in "command" everywhere else it appears in running prose.
|
Great work @serhiy-bzhezytskyy ...... So looking at this more, and looking at the PostTool.java, and the fact that the name of the file is "PostTool" and then, looking at how we refer to things in #3254, for example "This tool does not yet support PicoCli", that then makes me feel like we need to either pick "Tool" or "Command" and then lean into the specific name, across BOTH the java code and the ref guide docs. That I think helps us the most, because we know how to grep for the code in both ref guide and source, etc. For what it's worth, Picocli uses @janhoy WDYT? |
These can be both tools and commands. The individual classes are tools, and they can be invoked either from the CLI in which case it makes sense to document it user-facing as a bin/solr command. But PostTool can also be run standalone or embedded in some other bootstrap I suppose (at least it could earlier). I think we should keep the Tool naming in the code but refer to them as commands in the context of bin/solr. |
I can get behind that. So then in places where we emit something via bin/solr, like the I like that. |
|
So, I hope this recasts where to go @serhiy-bzhezytskyy:
|
The --mode help description, the warn() prefix, and the verbose
completion message each named the class directly ("Post tool", "reads
a command", "PostTool: WARNING:", "StreamTool -- Done."). None of that
naming is needed for the text to make sense, so it is dropped rather
than swapped for the other name. No other tool in this package prefixes
its warnings with a class name.
|
Pushed a commit dropping the class-name wording from the printed text: the --mode help description, the warn() prefix, and the verbose completion message. No other tool in this package prefixes its warnings with a class name, so that's dropped rather than swapped for the other name. The redirect for the third item is already live from the earlier commit - see the reply above on the post-tool.adoc:1 thread, post-tool.html/stream-tool.html redirect to the renamed pages. |
…he guide The help text of bin/solr post --mode should not name the tool or the command, and the wording proposed in review does that. The Post Command page shows the printed help verbatim, so its --help block follows the new text; it still had the old sentence, the last "Post tool" left in the guide.
|
Used your wording for the |
| .argName("mode") | ||
| .desc( | ||
| "Which mode the Post tool is running in, 'files' crawls local directory, 'web' crawls website, 'args' processes input args, and 'stdin' reads a command from standard in. default: files.") | ||
| "Which mode this runs in, 'files' crawls local directory, 'web' crawls website, 'args' processes input args, and 'stdin' reads from standard in. default: files.") |
https://issues.apache.org/jira/browse/SOLR-18463
Description
The ref guide has two pages,
post-tool.adocandstream-tool.adoc, that callbin/solr postandbin/solr stream"the Post Tool" and "the Stream Tool" (and, in two places, the one-word formsPostTool/StreamTool). Both used to be standalone tools, but are now bin/solr subcommands, so the "Tool" framing reads as if they were still separate products. The classes keep theirToolnames; only what a user ofbin/solrreads changes.Solution
post-command.adocandstream-command.adocwith the titles "Solr CLI Post Command" and "Solr CLI Stream Command".:page-aliases:keeppost-tool.htmlandstream-tool.htmlworking as redirects, and the navigation files point at the new pages. The prose says "Post command" / "Stream command" (lower case), with "Solr CLI Post command" on the first mention intutorial-diy.adoc.bin/solrprints no longer says "Tool" or "Command": the--modehelp ofbin/solr postuses the wording suggested in review, the warning prefixPostTool:and the verbose completion messageStreamTool -- Done.lose the class name. The--helpoutput block on the Post Command page shows the same text.xref:...[]links to these pages use empty link text, so they pick up the new titles automatically.Tests
./gradlew :solr:core:compileJava :solr:core:compileTestJava :solr:core:spotlessCheck -Pvalidation.errorprone=trueis clean.PostToolTest(14 tests) andStreamToolTest(11 tests) pass.buildLocalAntoraSiteandcheckSiteLinkspass with no broken links; the only Antora messages are six (five warnings and one table-row error, inconfigsets-api,rule-based-authorization-pluginanddocument-enrichment-with-llms) that #4922 (SOLR-18464) fixed on main after this branch was cut; this PR does not touch those pages.AI-assisted (Claude Sonnet 5).