anchor.diff:  
   A Package in Solr may contain one or more .jar files and any no:of plugins.
   
  +== Objectives
  +
  +* Zero disruption deployment (hot deployment): Should be possible to install and update packages without node restarts or core reloads, and hence deployments should be quick and without failed requests or stale caches.
  +* Easy packaging:
  +** Standard plugin concepts, e.g. query parser, search component, request handler, URP etc., should be supported without any special code/packaging changes.
  +** Artifacts (jars containing custom plugins) that users have already deployed (and are using in production) should be compatible, without needing to recompile or re-package, for greater adoption.
  +** Should support single jar packages as well as multiple jar packages.
  +** Use familiar / standard naming
  +** Use industry standard concepts and terminology around package manager, similar to those like apt, dnf, homebrew etc.
  +
  +
  +== Classloaders
  +
  +At the heart of the system, we have classloader isolation. To achieve this, the system is simplified into two layered classloaders:
  +The root classloader which has all the jars from Solr classpath. This requires Solr node restart to change anything.
  +A set of named classloaders that inherit from the root classloader. The life cycles of the named classloaders are tied to the package configuration in ZK. As soon as the configuration is modified, the corresponding classloaders are reloaded and components are asked to reload.
  +
   
   == A Plugin
   
  
positive.code: ** `add` command: add a version of a package
  ** `delete` command :  delete a version of a package
  
  ==== Using them in Plugins
  Any class name can be prefixed with the packagename e.g : `mypkg:fully.qualified.ClassName` and Solr would use the latest version of the package to load the classes from.
  
  example:
  
  1) create a package
  
  
negative.code: 
  For every package/version in the packages definition, there is a unique `SolrResourceLoader` instance. This is a child of the `CoreContainer` resource loader.
  
  === `packages.json`
  
  The package configurations live in a file called /packages.json in Zookeeper. At any given moment we can have multiple versions of a given package in the package configuration. The system will always use the latest version . Versions are sorted by their numeric value and the biggest is the latest.
  
  *example:*
  
  [source, json]
  ----
  {
   "packages" : {
     "mypkg" : {
       "name": "mypkg",
       "versions": [
         {"version" : "0.1",
         "files" : ["/path/to/myplugin/1.1/plugin.jar"]
         },
         {"version" :  "0.2",
         "files" : ["/path/to/myplugin/1.0/plugin.jar"]
         }]}},
  
  ----
  
  === API end points
  
  * `GET /api/cluster/package` Get the list of packages
  