anchor.diff:  These concepts are expressed in the `uberfire-commons` package,
   which contains a mix of server-only definitions shared client/server definitions.
   
  -* Clustering (server-only, see also UberFire I/O)
   * Data
    ** Pair, a generic 2-tuple (client + server)
    ** Triple, a generic 3-tuple (client + server)
    ** Cacheable, interface that provides explicit visibility of cached data.
   * Lock Service (server-only)
  -* Messaging (server-only, distinct from Errai Bus messages)
  -+
  -Provide for clustered deployments;
  ++
  +Common service interface to implement locks. Provides a `Thead` default implementation.
  +* Clustering (server-only, see also UberFire I/O)
  ++
  +A general clustering abstraction that provides a combination of `Lock` and `Message` services in a clustered environment (multiple computers).
  +* Messaging
  ++
  +General purpose messaging abstraction (server-only, distinct from Errai Bus messages). Currently implemented by IO clustered setup.
  +
  +** Message
  ++
  +Message is basically a composition of a `MessageType` and a `Map` of arbitrary values.
   ** AsyncCallback
   +
  -TODO
  +Async callback mechanism used to by call and wait messaging broadcast. Currently used to sync file systems in the cluster during startup.
   ** MessageHandler
   +
  -TODO
  +Interface that process messages, messages are routed to MessageHandler by `MessageHandlerResolver`.
   ** MessageHandlerResolver
   +
  -TODO
  +Simple routing mechanism to `MessageHandler` 's.
   ** MessageService
   +
  -TODO
  +Common service interface to implement broadcast (sync/async) and participant specific messaging exchange.
   ** MessageType
   +
  -TODO
  +Simple message classification. Usually used by `MessageHandlerResolver` in order to route a message to a proper `MessageHandler`.
   
   * CDI Startup Beans (the @Startup annotation) (server-only)
   * PortablePreconditions (client + server), a collection of static methods for checking common preconditions (reference not null, list not empty, etc.)
  
positive.code: the following concepts, and one implementation of the API (a "metadata
  backend") that relies on Apache Lucene:
  
  TODO
  
  * Metadata index engine
  * Metamodel store
  * "K" objects:
  ** KObject
  ** KObjectKey
  ** KObjectSimpleKey
  ** KProperty
  ** KPropertyBag
  * MetaObject
  * MetaProperty
  * MetaType
  * Cluster segment
  * Date range
  * Search index
  
  There is also a small submodule called `uberfire-metadata-commons-io`
  which introduces the following concepts:
  
  * Batch index
  * IO Service Provider
  ** Index
  ** Search
  
  UberFire NIO2 Concepts
  ~~~~~~~~~~~~~~~~~~~~~~
  
negative.code: ~~~~~~~~~~~~~~~~~~~~~
  
  These concepts are expressed in the `uberfire-io` package,
  which contains server-only code.
  
  * IOService
  +
  TODO
  
  ** AbstractIOService
  +
  TODO
  ** IOServiceNio2Wrapper
  +
  TODO
  ** IOServiceDotFile
  +
  TODO
  ** Clustered Service
  +
  TODO
  * Watch Service
  +
  TODO
  * Search Service
  +
  TODO
  * Attributes
  +
  TODO
  
  ** Dublin Core (TM) metadata
  +
  TODO
  
  UberFire JS Concepts
  ~~~~~~~~~~~~~~~~~~~~
  
  These concepts are expressed in the `uberfire-js` package, which
  exposes a JavaScript API for some aspects of the UberFire framework.
  This gives application developers the option to write UberFire
  applications partly or entirely in JavaScript.
  
  * JavaScript native plugin, with types representing
  ** Perspectives
  ** Plugins
  ** Workbench perspective activities
  