[
https://issues.apache.org/jira/browse/SOLR-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291264#comment-14291264
]
Erick Erickson commented on SOLR-7032:
--------------------------------------
ba: Bah, I thought I'd expunged all trace of this
You did a boatload of work, this is entirely minor.....
bq: They're not tripping any test failures, which suggests that they're
completely unused and we can safely rip them out
Yeah, which leads me to some questions about our test harness, why does the mr
test that synthesizes solr.xml code _not_ die in 5.0? Probably doesn't go down
the same parsing path maybe? Same with the multicore bits I took out.
bq: It looks as though there's going to be a respin for 5.0, so I think it's
worth getting this in.
Easy enough to do, but leaving them in 5.0 isn't doing any harm either. I don't
have strong feelings one way or the other, it'd be nice not to have even these
remnants in to make 5.0 clean, but is that aesthetic worth the (minimal I
admit) risk? Anyone else want to weigh in?
> Clean up test remnants of old-style solr.xml
> --------------------------------------------
>
> Key: SOLR-7032
> URL: https://issues.apache.org/jira/browse/SOLR-7032
> Project: Solr
> Issue Type: Improvement
> Affects Versions: Trunk, 5.1
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
> Fix For: Trunk, 5.1
>
> Attachments: SOLR-7032.patch
>
>
> After Alan's heroic work with pulling out support of old-style solr.xml,
> there are still a few mentions in some of the test code and a couple of
> places where solr.xml is synthesized inline found just by grepping on
> "<cores".
> The code itself will throw an error when processing solr.xml if there are
> <cores> or <core> tags, so there's no reason to try to get this patch in to
> 5.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
