[
https://issues.apache.org/jira/browse/SOLR-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642817#comment-14642817
]
Shawn Heisey commented on SOLR-7043:
------------------------------------
Separately, I've been thinking a little bit about the solr.in.* scripts, if we
choose to continue using bash/batch. Some of the documentation suggests
editing those for customization, but I don't think that's a good idea. I think
that user customizations should go in a completely separate file that we don't
include with Solr, to be read after the solr.in.* script. The reason I think
that's a good idea is that any user who upgrades by replacing all their files
with the new archive will lose any customizations to the solr.in.* scripts.
Enough stuff happens in those scripts that an install might be harmed if they
continue to use their existing scripts and don't migrate their customizations
to the new version.
Thinking along the same lines (easing upgrades), the config file for the new
Java commandline program should not actually exist in the download ... if it
has a name like startup.xml or solr.yml, the file included in the download
should be startup.xml.example or solr.yml.example, and in the absence of the
real file, all settings should assume reasonable defaults, most likely whatever
solr and solr.cmd are doing currently.
> Refactor SolrCLI, bin\solr, bin\solr.cmd to be more unit-testable and less OS
> specific
> --------------------------------------------------------------------------------------
>
> Key: SOLR-7043
> URL: https://issues.apache.org/jira/browse/SOLR-7043
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
> Reporter: Timothy Potter
> Assignee: Timothy Potter
>
> With the 5.0 release, we've reached critical mass with the bin/solr script
> interface, but we've picked up some cruft along the way. Specifically,
> there's too much OS-specific constructs in the scripts and they are quite
> complex overall. They also require extensive manual testing. Moreover,
> SolrCLI (provides support for the scripts) needs to be refactored to use the
> Collections API support added to SolrJ instead of using low-level JSON / HTTP
> constructs. SolrCLI is also in desperate need of a unit test. The overall
> goal of this ticket is to move as much as possible out of the shell scripts
> and into SolrCLI, thus increasing test coverage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
