[
https://issues.apache.org/jira/browse/SOLR-11946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352704#comment-16352704
]
Jason Gerlowski commented on SOLR-11946:
----------------------------------------
Wanted to post some notes I gathered while working on the above patch. Might
be helpful for any potential reviewers.
Most of the difficulties in moving this logic to Java come from working with
the functionality that we get OOB with the {{commons-cli}} package. However,
all of these have workarounds:
- {{commons-cli}} doesn't have support (AFAICT) for having a single option
with more than 1 "long-option". For example, the {{bin/solr create}} command
treats {{-c}}, {{-collection}}, and {{-core}} as the same option.
{{commons-cli}}'s
[OptionBuilder|https://commons.apache.org/proper/commons-cli/javadocs/api-1.3.1/org/apache/commons/cli/OptionBuilder.html]
allows you to accept "collection", or "core", but not both. This has an easy
workaround though: just create two different {{Option}} instances that share
the same shortopt ({{-c}}, in our example).
- {{commons-cli}} generates help/usage text from the list of options. But
current {{bin/solr}} code passes some arguments not provided (directly) by the
user. An example of this is the constructed {{solrUrl}} parameter that is
usually built from default constants, an auto-detected Solr port, etc. If
{{solrUrl}} (for example) is parsed with the other command line options, it
will appear in the help text, which would confuse users. This also has an easy
workaround: "internal" options can be passed from scripts to SolrCLI as
environment variables or Java system-properties, instead of in the command line
args.
- Even with the ability to "hide" some internal options (see above), the
{{commons-cli}}
[HelpFormatter|https://commons.apache.org/proper/commons-cli/javadocs/api-1.3.1/org/apache/commons/cli/HelpFormatter.html]
usage/help text doesn't quite match the current help text spat out by the
scripts. In most cases, this is just a matter of spacing and can probably
safely be ignored, though some differences/limitations are harder to work
around. I am not sure whether interface-backcompat promises extend to the help
text in the {{bin/solr}} scripts. If they do, we can ensure we maintain
backcompat by copying the help text verbatim in to the Java code. (This still
reduces duplication, as the help text currently lives in both the Windows and
Linux scripts.). Otherwise, maybe moving to {{HelpFormatter}} based help text
is acceptable here.
> Move bin/solr arg-parsing logic to Java
> ---------------------------------------
>
> Key: SOLR-11946
> URL: https://issues.apache.org/jira/browse/SOLR-11946
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
> Affects Versions: master (8.0)
> Reporter: Jason Gerlowski
> Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-11946.patch
>
>
> Currently, there is logic in three different places that parses arguments for
> the {{bin/solr}} scripts. There is logic in the scripts themselves
> ({{bin/solr}}, {{bin/solr.cmd}}), and there is logic in Java to parse the
> arguments sent by the scripts themselves ({{SolrCLI.java}}.
> This creates maintenance burden. It makes it easy for inconsistencies/bugs to
> creep into the scripts (see SOLR-11840 and SOLR-11441, for a few examples).
> It adds work when adding/removing/modifying {{bin/solr}} script behavior.
> And it forces anyone hoping to improve the scripts to be conversant in both
> bash and Windows batch scripting.
> It would be a big help if _all_ the argument parsing was done on the Java
> side, and little or none was done in the scripts themselves. There are a few
> situations in which this is difficult, but in no cases is it impossible.
> We should move this logic into Java-land.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
