[
https://issues.apache.org/jira/browse/SOLR-11206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117815#comment-16117815
]
Jason Gerlowski commented on SOLR-11206:
----------------------------------------
*Questions/Concerns/Thoughts*
Most of these are just some notes I wanted to jot down for my own benefit.
Though they may provide helpful for others to catch my
mistakes/misconceptions...
* AFAIK, there are no tests for the bin/solr scripts themselves, are there?
I'm concerned about inadvertently introducing bugs that will cause users issues
down the road. With that in mind, one of my first steps here might be to put
together a script which exercises the {{bin/solr}} commands in many ways. It's
obviously not feasible to capture all cases, but a gap/hole-ridden benchmark is
better than none at all.
* A "benchmark" script like the one suggested above could be used to diff the
output before and after this refactor, to ensure that the output isn't changing
in any ways we don't expect/anticipate/want. Do the backcompat guarantees made
elsewhere in Solr extend to the output of these scripts as well? Or is there
not a rigid expectation around that?
* I suspect I might run into some discrepancies in behavior between the two
bin/solr implementations. I suppose these will just have to be handled on a
case by case basis (as far as determining which behavior should be taken
forward.)
> 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)
>
>
> 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]
