Changed POM versions to '3.1-SNAPSHOT'
Federation - Added initial DocumentStore implementation and replaced SchematicDB usages. All tests pass.
Federation - Added federation manger to modeshape-api and a draft connector interface/integration
Federation - Updated federation design:
-separated DocumentStore into LocalDocumentStore and FederatedDocumentStore
-introduced ConnectorManager
-removed Metadata dependencies
Federation - Implementing the persistence support for "reading" federated nodes. Also, added a test case which uses mocked data for testing the reading behavior.
Federation - Updated the federation test and fixed missing information in the documents that the connector wasn't providing: parent references, primary type.
Federation - Updated the connectors and document store with write information
Federation - Updated the design of the "write interfaces" and added a unit test for validating the writing of an external node. Also, implemented a mechanism for storing the parent back reference for the federated - external node.
Federation - A few enhancements to the federation framework (configuration, management, etc.):

- Connectors can now be configured within a repository's configuration; documents reflecting each connector's configuration (e.g., classname, classloader, connector-specific properties) appears as a value in the field named by the connector under the "storage/connectors" document. The 'repo-config-federation.json' test configuration was updated to configure the MockConnector.
- MockConnector is now a separate (deprecated) class, and is configured like any other connector (via the configuration file) and thus is no longer hard-coded.
- ConnectorsManager was renamed to Connectors (following the same pattern for the existing Sequencers container class) and moved into the 'org.modeshape.jcr' package so it can be initialized with JcrRepository.RunningState (again, like Sequencers) through which the Connectors class can access the repository's ExecutionContext, MIME type detector, and other components. Connectors can still be added and removed dynamically (though this is not yet supported in the JcrRepository.RunningState constructor) via 'addConnector(Component)' that reuses the same RepositoryConfiguration.Component used by RepositoryConfiguration for sequencers, text extractors, and other components. Connectors are removed by name.
- Connector is now abstract and contains quite a few helper methods, including methods to create document builders (now an interface), names, and to return the value factories (which connectors will use to create property values). Connector also has lifecycle methods (e.g., initialize and shutdown) that are called by the Connectors class. Several private fields are also initialized (reflectively) by the Connectors class.
- FileSystemConnector is a new, initial implementation of a connector that accesses the file system. It is still relatively crude (and untested), and doesn't yet support extra properties like in 2.x (not sure we want to do this, although several 2.x users were leveraging this feature).
Federation - Extracted a separate class for handling federated child references
Federation - minor changes to how the repository configuration's specifies the external sources (previously called 'connectors'
when we're really talking about external sources).
Federation - Updated federation so that external projections are now named using an alias and also added additional write tests
Federation -Implemented cache TTL configuration option, so that external nodes caching is configurable both at a connector (default) level and for each external document
Federation - Improved Connector SPI and file system connector

The Connector SPI was improved, particularly the DocumentReader and
DocumentWriter interfaces and implementations. (That implementations
now reuse logic from DocumentTranslator, since the impls logic was
non-trivial and contained several errors and bugs.)
The JavaDoc of the Connector methods was changed to define the
acceptable runtime exceptions. And the FileSystemConnector was
improved to better support reads and writes.

There still are several issues, however.

First, the getName() and getPath() of the JCR nodes representing
external nodes return the wrong information. Since both name and
path are based upon the path of the node, I believe there is an
error within the parent logic for external nodes. However, I didn't
have time to track this down.

Secondly, the mechanism by which changes to nodes are sent to the
connector (ultimately thru the 'update' SPI method) is not ideal.
For example, consider that a external node has lots of properties (
including one or more very large BINARY value). When a client
adds a single property to this node via the JCR API, ModeShape
reads the entire node document from the connector (with all of the
large properties), changes the node's document, and the pushes the
entire (changed) node document down to the connector. The connector
then has to write out the full state of the node, including all
of the large properties.

Normally, with Infinispan for storage, we do want/need to persist
the whole (changed) node document. However, for connectors we likely
will want to know which parts of the node document have changed
so that the connector can just update what's been changed (e.g.,
in the example, the connector should really just have to add
the new property to its storage system).

The DocumentStore is obtaining an editor for the document, so it's
possible that the FederatedDocumentStore needs to return a fully-
functional editor so that it can record what is changed and submit
that to the connector via the 'update' method.

Note that this second issue is purely related to performance
and cost of connector operations. So for the time being it might
be fine. However, I think we should consider changing the
connector.update(...) signature to perhaps *also* pass a parameter
that describes what's changed (e.g., a "delta" representation).
Federation - Implemented a paging mechanism for the connectors which makes use of the standard block segments. Updated the mock connector to simulate pagination for a node, so that the functionality can be tested.
Federation - Corrected the FileSystemConnector's use of the parent references

The FileSystemConnector was not setting the reference to each node's parent, and this was the cause of the incorrect names and paths. The connector appears to be working now for basic operations, although move and renames are still a challenge.
MODE-1703 fixed problems with invalid deserialization of Path and AddValueOperation, still doesn't solve problem as we start to get NullPointerException in ArrayOperation.mutableParent
MODE-1703 Corrected serialization of Schematic deltas

Array objects were not being serialized/deserialized properly
within the delta's operation instances (e.g., PutOperation).

Normally, all SchematicEntry (e.g., Documents containing values
such as Arrays and other Documents) are serialized using BSON, and
this works correctly in the non-clustered case. However, in the
clustered case, the changes made to one Document are recorded to
create a SchematicEntryDelta that is shipped across the Infinispan
cluster. (This way we can ship only the changes to the
SchematicEntry rather than the whole document.) Thus the problem
only manifest itself in clustered configurations.

The actual problem stemmed from the fact that an
SchematicEntryDelta and its Operation objects are all
externalizable (with custom Externalizers). The Operation objects
can contain individual values, Document or Array objects. These are
also externalizable, but there was a single DocumentExternalizer
for both Document and Array objects and the DocumentExternalizer
wrote/read both to/from BSON.

However, the BSON format (which is simply a binary representation
of JSON documents, with a few extra value types) is only valid for
Documents; a standalone Array cannot be written in BSON format.

The solution was to use the DocumentExternalizer for Documents, but
a new ArrayExternalizer for Arrays. This ArrayExternalizer still
uses BSON, but it uses a subset of the BSON representation to
serialize Array objects. But, it does work well and fixes the
problem.

Quite a few new tests were added to verify that the various
operations with various parameters are indeed externalizable. The
tests don't cover all the permuations, but they do attempt to cover
the different kinds of operations with documents and arrays.

To make the Operation objects easily testable, equals and hashCode
methods were added to all the Operation subclasses. Additionally,
all of the externalizers were manually reviewed for asymmetric read
and write methods (e.g, writing an object to the ObjectOutputStream
but reading an integer from the ObjectInputStream), and several
asymmetries were found in the Externalizers for BSON value types
that ModeShape doesn't currently use, and these asymmetries were
corrected.

All unit and integration tests pass with these changes.
MODE-1703 Minor improvements

Based upon feedback, two sections of commented-out code were removed (they'd been there
for some time) and the Code.Externalizer methods were changed to use constants rather
than magic numbers for the types of the Code classes.
MODE-1693 - Added special handling to the case when transactions are not configured: a dedicated exception should be thrown