Hmmmm. Point taken about not exposing a pluggable version yet, now that you mention it that seems premature. Hardening all that before exposing something we then have to support makes sense. We can still program to the interface I mentioned as much as possible to make that easier in future but no big deal either way.
<1> is done.
<2> OK, what does that look like? Is this just a simple transformation like
<solrConfigFactory name="solrConfigFactory" clase="SolrConfigFactory">
<shardHandlerFactory name="shardHandlerFactory" class="HttpShardHandlerFactory">
This form doesn't allow cores to be here at all. Is there any necessity to have a factory here or are you thinking these should just be child nodes of <solr>? Would shardHandlerFactory be inside or outside the new factory? As you can tell, how all this fits together is something of a mystery to me. But having a solrConfigFactory node as the immediate child of <solr> and encompassing all the rest would allow easy detection of old
vs new style XML. Adding a version attribute to the <solr> tag seems possible too, but I don't really like that, I think there's less user-level maintenance if we use solrConfigFactory, implementing up different handlers for different versions if/when we change again, which should be very rare.
<3> On that note, it's not clear to me we need solr.xml at all in "true cloud mode". In the absence of solr.xml but presence of zkHost, just get everything from ZK. Look, you know how ZK-ignorant I am, be gentle <G>. The rest of the time, anything you could possibly want from solr.xml that wasn't present, ask ZK for it and use defaults if neither source had it. By "not present", that means neither in the solr.xml file nor as a sysprop. Along the way removing DEF_SOLR_XML from ConfigSolrXml would be a Good Thing maybe.