[
https://issues.apache.org/jira/browse/SOLR-11206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129789#comment-16129789
]
Jason Gerlowski edited comment on SOLR-11206 at 8/17/17 2:40 AM:
-----------------------------------------------------------------
My access to Windows is spotty, and so I haven't been able to get an
output-benchmark from a Windows machine yet, though I should have access and
time to do so tomorrow.
In the meantime, I'm uploading a proof-of-concept patch for one of the commands
supported by the control-scripts ("create").
Notes/caveats on the patch:
- I chose "create" because it had enough arguments to demonstrate the value in
the change.
- As I mentioned above, I haven't had Windows access recently, so there might
be issues with the {{bin/solr.cmd}} changes. Though the changes are accurate
enough to show the approach.
- As-is, the patch matches command output on success, but error messages about
missing/invalid arguments don't line up exactly with the pre-patch code. The
argument parsing in Java-land uses the commons-cli library, which makes the
parsing concise/convenient, but ties us to the error-message format dictated by
the library. I'm curious what the backward-compatibility expectations are
around the output of the bin/solr scripts. I've heard guidelines for the Java
code, and for API output, but not for the control scripts. We can match all
stdout output if we eschew commons-cli, but the library is so standard and
makes the code so maintainable that I'd like to lobby for using it if it
doesn't stretch/break our backward-compatibility promises/expectations. Could
use some guidance here.
was (Author: gerlowskija):
My access to Windows is spotty, and so I haven't been able to get an
output-benchmark from a Windows machine yet, though I should have access and
time to do so tomorrow.
In the meantime, I'm uploading a proof-of-concept patch for one of the commands
supported by the control-scripts ("create").
Notes/caveats on the patch:
- I chose "create" because it had enough arguments to demonstrate the value in
the change.
- As I mentioned above, I haven't had Windows access recently, so there might
be issues with the {{bin/solr.cmd}} changes. Though the changes are accurate
enough to show the approach.
- As-is, the patch matches command output on success, but error messages about
missing/invalid arguments don't line up exactly with the pre-patch code. The
argument parsing in Java-land uses the commons-cli library, which makes the
parsing concise/convenient, but ties us to the error-message format dictated by
the library. I'm curious what the backward-compatibility expectations are
around the output of the bin/solr scripts. I've heard guidelines for the Java
code, and for API output, but not for the control scripts. We can match all
stdout output if we eschew commons-cli, but the library is so standard and
makes the code so maintainable that I'd like to lobby for using it if it
doesn't stretch/break our backward-compatibility promises/expectations.
> Migrate logic from bin/solr scripts to SolrCLI
> ----------------------------------------------
>
> Key: SOLR-11206
> URL: https://issues.apache.org/jira/browse/SOLR-11206
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
> Reporter: Jason Gerlowski
> Fix For: master (8.0)
>
> Attachments: ctrl-script-output-benchmark.sh,
> linux-initial-output.txt, SOLR-11206.patch
>
>
> The {{bin/solr}} and {{bin/solr.cmd}} scripts have taken on a lot of logic
> that would be easier to maintain if it was instead written in Java code, for
> a handful of reasons
> * Any logic in the control scripts is duplicated in two places by definition.
> * Increasing test coverage of this logic would be much easier if it was
> written in Java.
> * Few developers are conversant in both bash and Windows-shell, making
> editing difficult.
> Some sections in these scripts make good candidates for migration to Java.
> This issue should examine any of these that are brought up. However the
> biggest and most obvious candidate for migration is the argument parsing,
> validation, usage/help text, etc. for the commands that don't directly
> start/stop Solr processes (i.e. the "create", "delete", "zk", "auth",
> "assert" commands).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
