]]>
  </description>
  <defaults>
    <default>
      <key>package</key>
      <value>org.apache.maven.settings</value>
    </default>
  </defaults>
  <classes>
    <class java.clone="deep">
      <name>TrackableBase</name>
      <version>1.0.0+</version>
      <description>
        common base class that contains code to track the source for
        this instance (USER|GLOBAL)
      </description>

    /**
     * Returns the default instance of the particular type of toolchain, can return <code>null</code>
     * if not applicable.
     * TODO keep around??
     **/
    ToolchainPrivate createDefaultToolchain();

                     * Not patching an existing module. This case should be unusual. If it nevertheless
                     * happens, add on class-path or module-path if allowed, or keep patching otherwise.
                     * The latter case (keep patching) is okay if the main module will be defined later.
                     */
                    type = cache.selectPathType(pathTypes, filter, path).orElse(type);
                }

                    wagon.removeTransferListener(md5ChecksumObserver);
                    wagon.removeTransferListener(sha1ChecksumObserver);
                }

                if (downloaded) {
                    // keep the checksum files from showing up on the download monitor...
                    if (downloadMonitor != null) {
                        wagon.removeTransferListener(downloadMonitor);
                    }

     * dependency management entries in transitive dependency POMs. Maven 4 enables "transitivity" by default, hence
     * unlike Maven2, obeys dependency management entries deep in dependency graph as well.
     * <p>
     * Default: {@code "true"}.
     *
     * @since 4.0.0
     */
    private static final String MAVEN_RESOLVER_DEPENDENCY_MANAGER_TRANSITIVITY_KEY =

 *
 */
public interface InheritanceAssembler {

    /**
     * Merges values from the specified parent model into the given child model. Implementations are expected to keep
     * parent and child completely decoupled by injecting deep copies of objects into the child rather than the original
     * objects from the parent.
     *

                     * Not patching an existing module. This case should be unusual. If it nevertheless
                     * happens, add on class-path or module-path if allowed, or keep patching otherwise.
                     * The latter case (keep patching) is okay if the main module will be defined later.
                     */
                    type = cache.selectPathType(pathTypes, filter, path).orElse(type);
                }

searching to particular classes. The application ClassRealm, or parent ClassRealm, should only expose the API in the form of and application interface and model classes that may be required by plugins.

For debugging purposes we also need to keep track of what versions of artifacts are being used so that when we are debugging in the IDE we can find the specific sources for a given version of a library so that the developer can debug the correct version of a library being used for a plugin....