While working on SOLR-10493 my mental model was that the CoreDescriptors should not be possible to create without a core.properties file. Of course that's not the case, all you have to do is pass properties to the CoreDescriptor c'tor.
In fact, CorePropertiesLocator reads the core.properties file into a Map in order to pass it to the CoreDescriptor c'tor. This was all necessary when we supported the old-style core definitions in solr.xml, but seems unnecessarily trappy now. Then there's the "loadExtraProperties" in there which is decoupled from loading the properties in the first place, again I think a remnant of supporting both styles of core definition. Now that we're in the brave new world of core discovery only, WDYT about nuking the methods in CoreDescriptor that take Maps and instead requiring that we pass in a file (or Path) to core.properties? I suspect this could be quite a large change to the tests and really haven't explored what it would take. My purpose here is to see what people think of the idea. I'm not sure what _I_ think of it in the first place, but from the perspective of eating our own dog food, very few tests really even try to use core.properties files, so we don't test the real, true only way to define a core. There's be some interesting problems to solve here I'm sure. Replica creation comes to mind, I'm not sure what the sequence for creating the core.properties files is for instance. Create the CoreDescriptor first then persist it? And maybe it's just fine the way it is, just askin' what people think... Erick --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
