In general there is a direct analog from the legacy format to the new format except there is no <cores> element nor are there any <core> elements in discovery-based Solr.
In Solr 4.4 and on, the presence of a <cores> child element of the <solr> element in the solr.xml file signals a legacy version of solr.xml, and cores are expected to be defined as they have been historically. Depending on whether a <cores> element is discovered, solr.xml is parsed as either a legacy or discovery file and errors are thrown in the log if legacy and discovery modes are mixed in solr.xml.
Moving <core> definitions.
To migrate to discovery-based solr.xml, remove all of the <core> elements and the enclosing <cores> element from solr.xml. See the pages linked above for examples of migrating other attributes. Then, in the instanceDir for each core create a core.properties file. This file can be empty if all defaults are acceptable. In particular, the instanceDir is assumed to be the directory in which the core.properties file is discovered. The data directory will be in a directory called “data” directly below. If the file is completely empty, the name of the core is assumed to be the name of the folder in which the core.properties file was discovered.
As mentioned elsewhere, the tree structure that the cores are in is arbitrary, with the exception that the directories containing the core.properties files must share a common root, but that root may be many levels up the tree. Note that supporting a root for the cores that is not a child of SOLR_HOME is supported through properties in solr.xml. However, only one root is possible, there is no provision presently for specifying multiple roots.
The only restriction on the tree structure is that cores may not be children of other cores; enumeration stops descending down the tree when the first core.properties file is discovered. Siblings of the directory in which the core.properties file is discovered are still walked, only stopping recursing down the sibling when a core.properties file is found.
Here’s an example of what a legacy solr.xml file might look like and the equivalent discovery-based solr.xml and core.properties files:
The new-style solr.xml might look like what is below. Note that adminPath, defaultCoreName are not supported in discovery-based solr.xml.
In each of “core1″ and “core2″ directories, there would be a core.properties file that might look like these. Note that note that instanceDir is not supported, it is assumed to be the directory in which core.properties is found.
In fact, the core2 core.properties file could even be empty and the name would default to the directory in which the core.properties file was found.