[
https://issues.apache.org/jira/browse/SOLR-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642796#comment-14642796
]
Shawn Heisey commented on SOLR-7043:
------------------------------------
bq. Also, should we deprecate the OS-dependent solr.in.cmd and solr.in.sh in
favor of some new solr.yml or something? Then SolrCLI would find and parse the
file.
I do like the idea of having a configuration file for Solr startup, but it
should be in one of the two config languages which are predominant in Solr
already -- .xml and .properties. I cannot debate on the technical merits of
yml, because I know nothing at all about it. I can say that I'm not interested
in adding another configuration language, both from the standpoint of user
education and code to handle it. If anything, we need to consolidate all
configuration to a single format, and I think the strongest contender for that
is probably JSON, though that would involve considerably more code change than
XML.
+1 on the idea of a little java program so that the jobs being done by script
are implemented exactly once and will work on any platform. One of the ideas
from [[email protected]] in the "make Solr a standalone program" thread
that I really liked was turning Solr into two programs -- Solr itself and an
agent that can start, stop, and configure Solr. This could be a first step
towards that.
> 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]
