Clone Tools
  • last updated a few minutes ago
Constraints: committers
Constraints: files
Constraints: dates
MODE-2527 Renames the schematic package to org.modeshape and removes all ISPN related code.

    • -1679
    • +0
    • -68
    • +0
  1. … 306 more files in changeset.
MODE-2164 Added test to validate System.env() properties are substituted.

  1. … 1 more file in changeset.
MODE-2148 Added checkstyle to our build, and corrected numerous potential problems or issues in the code. Also removed lots of meaningless JavaDoc

  1. … 366 more files in changeset.
MODE-2081 Changed the license for ModeShape code to ASL 2.0.

    • -16
    • +10
    • -16
    • +10
  1. … 112 more files in changeset.
Corrected compiler warnings and removed unnecessary JavaDoc

  1. … 20 more files in changeset.
MODE-1853 - Updated the code so that "unwrap" is called in more places, trying to avoid the risk of Document & Array editors being passed in.

  1. … 8 more files in changeset.
Removed unused imports

  1. … 1 more file in changeset.
MODE-1729 - Added AS7 integration test and updated configuration to use an external filesystem source.

  1. … 3 more files in changeset.
MODE-1711 - Implemented the ability to specify projections via the repository configuration file

  1. … 14 more files in changeset.
MODE-1711 - Updated schema validation mechanism so that items from the "additionalProperties" section are validated if they have a schema defined.

  1. … 7 more files in changeset.
MODE-1474 - Changed schema validation so that "enum" validation is case insensitive

  1. … 3 more files in changeset.
MODE-1715 Additional correction to the variable replacement logic

The logic was incorrectly replacing blank values with null values. All works well now.

  1. … 1 more file in changeset.
MODE-1715 Additional correction to the variable replacement logic

The logic was incorrectly replacing blank values with null values. All works well now.

  1. … 1 more file in changeset.
Fixed javadoc errors that occurred when moving from Eclipse Helios to Eclipse Indigo. Also fixed a pom error that occurred when upgrading Eclipse.

  1. … 20 more files in changeset.
MODE-1522 Changed the sequencer portion of the JSON configuration

Previously the sequencers were defined in the JSON configuration using an array of nested

documents. However, this made it difficult to easily identify and update a particular sequencer

configuration. And even though the names were intended to be unique, using an array did

not enforce that constraint. Finally, the sequencer configurations are not ordered.

Now, the 'sequencing/sequencers' field in the JSON configuration files are documents,

with the field name containing the unique name of the sequencer. The value of these

fields are each the sequencer configuration for the given name.

An error in the JSON Schema validation logic was discovered and corrected. Note that very

few of the changes involved the production code; most changes were in fact for test code

or configurations.

  1. … 26 more files in changeset.
MODE-1402 Changed repository configuration format to simplify sequencer configuration

Made a couple of changes to the repository configuration JSON Schema to simplify things

and remove unused or ancillary items:

- The sequencer, text extractor, and authentication provider components no longer have a

"name" field, since it was not much different than "description"

- The sequencer, text extractor, and authentication provider components have a "type"

field that is a superset of the older "type" and "classname" fields. The "type" field

is now required.

- The sequencer components no longer have a "pathExpression" and "pathExpressions" fields;

instead, there's just "pathExpressions" whose values are always arrays. Note that

"pathExpressions" is now a required field.

Lots of configuration files for the sequencer modules were changed (as was the online

documentation). Quite a few other classes needed to be changed to support the removal

of the "name" field from Component and Sequencers.

All unit and integration tests pass.

  1. … 24 more files in changeset.
MODE-1375 Added support for system property variables in repository configuration JSON documents

The JSON Schema validation logic already looked for cases where a field value object does

not have the correct type expected in the JSON Schema; such situations were reported as

errors (just like the other errors). This was changed so that, in these situations, the

schema validator tries to convert the actual value to the expected type; if that doesn't work,

the error is reported as usual, but if it can be converted, a special "mismatched type" error

is reported instead and includes the actual value, the converted value, the actual type,

and the converted type. (To public users, this is merely just a regular error, though.)

Also added a method to create a copy of a Document using a supplied `ValueTransformer` instance,

which the copy logic uses to transform each of the values within the Document. This copy

logic returns the same Document instance (not a copy) if no values were transformed, but

returns a new Document object if at least one value was transformed.

Added another method to create a copy of a Document using the validation results, where

we look for all of the "mismatched type" errors and use the converted value in place of the

actual value. (This process includes nested documents and arrays.)

Then the RepositoryConfiguration constructors were modified to try to create a copy

of the supplied document using a SystemPropertyTransformer; if a new Document were created

(because variables were replaced), then the new Document is validated against the schema

and any "mismatched type" values are used to create a copy of the document with the

mismatched values converted to the expected values. The RepositoryConfiguration then

uses the new Document with converted values, and the user can continue to validate

the configuration using the existing "validate()" method. This is where any problems

with the system properties will show up to the user. For example, if a variable is

replaced with a system property that cannot be converted to the type expected by the

JSON Schema for that field, a normal validation error will be included in the validation


In general, all this happens transparently to RepositoryConfiguration users.

    • -0
    • +366
    • -0
    • +57
  1. … 21 more files in changeset.
MODE-1365 Migrated JCR query functionality

Migrated the JCR query functionality from 2.x into the 3.x codebase.

At this point, all parsing and query object model code and tests have been moved,

all of the query-relate JCR interfaces have been implemented, and the internal

RepositoryQueryManager is created and wired up.

The repository configuration schema and RepositoryConfiguration class have been

changed to contain the indexing-related options, and we're creating and using the

Hibernate Search components correctly.

However, some work is still required:

- indexing content changes (upon and upon creating Binary values),

- generating the Lucene Query objects for the various JCR-JQOM criteria

(these methods have not yet been migrated)

As a result, queries parse but never return results.

All unit and integration tests pass.

    • -34
    • +168
    • -0
    • +17
  1. … 325 more files in changeset.
MODE-1289 New approach for storing/caching JCR content

This is the first commit to start the 3.0 effort, which involves a major change to how

the JCR layer stores and caches information. The new approach is based upon Infinispan and uses

Infinispan's cache loaders for persistence, and JSON-like documents (that are in-memory

structures not needing to parsed/written) are used to store information for each node.

There are several new Maven modules:

- modeshape-jcr-redux

- modeshape-schematic

The 'modeshape-jcr-redux' module will eventually replace the 'modeshape-jcr' module once

the implementation is far-enough along. And the 'modeshape-schematic' module will likely

move into the Infinispan project, so that needs to remain separate.

Although it may seem strange and unkempt to have the new JCR implementation in a new module,

doing so means that we can continue to rebase from 'master' (and the 2.7 work) for at least

some time. When the new module becomes complete enough, we'll move it and replace the

existing 'modeshape-jcr' module. It's also convenient to have both the old and new implementations

around in the same codebase.

The build was changed to focus upon the (few) modules that are oriented around the new

implementation. So the following can be used to build the newer codebase:

mvn clean install

However, the build has a new Maven profile called "legacy" that can be used to build the

old modules. We kept this to make sure that any rebasing can be compiled and verified.

For example, to build everyhing, including the new modules and the 2.x-style modules,

use the following command:

mvn clean install -Plegacy

As the newer 'modeshape-jcr-redux' progresses and other modules (e.g., sequencers, web,

jboss, text extractors) are converted to use the new module, they should be moved

from the 'legacy' profile into the main set of modules in the top-level 'pom.xml'

    • -0
    • +1448
    • -0
    • +58
    • -0
    • +141
    • -0
    • +65
    • -0
    • +145
  1. … 441 more files in changeset.