Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Changed components versions to 2.8.2.GA.

  1. … 67 more files in changeset.
MODE-1561 - Updated the TikaTextExtractor to support a "writeLimit" property which is passed down to Tika. If absent, the default Tika limit of 100k characters is used.

  1. … 6 more files in changeset.
'Release: update versions for modeshape-2.8.3.Final'

  1. … 70 more files in changeset.
'Release: update versions for modeshape-2.8.2.Final'

  1. … 70 more files in changeset.
MODE-1500 MODE-1501 Corrected AS7 integration (JNDI names and assemblies)

Several issues were identified and corrected. The first was that although the ModeShape engine

(e.g, the 'org.modeshape.jcr.api.Repositories' implementation) was registered in JNDI,

the Repository instances were not correctly being registered and were thus not able to be found

by deployed components. This was rectified, and now the engine and each repository is properly

registered in JNDI.

Secondly, the JNDI names where the engine and repositories are registered were changed to

more closely align with the naming patterns used by other implementations. The engine

is always registered at "jcr" in the "java:" namespace (i.e, "java:/jcr"), while each

repository is registered at "jcr/{repositoryName}" in the "java:" namespace. For example,

the repository named "sample" could be found in JNDI at "java:/jcr/sample" or "jcr/sample".

This conforms to the many examples that configure a JCR repository at "jcr/local"

(where only one repository is used).

Note that the new default JNDI names are different than ModeShape 2.x, which used "jcr/local" as the

location of the engine and "jcr/local/{repositoryName}" as the default location for each

repository. However, should the old style still be needed for a repository, the repository can

be configured with a custom JNDI name.

Thirdly, when a repository is configured to have a custom JNDI name, the repository is registered

under the specified name (as before), but now the repository is still registered under the

'jcr/{repositoryName}' name. This means that code can find the repository under either name.

Fourthly, the assembly for the ModeShape kit was moved from the 'deploy/jbossas' Maven module

(which installed the resulting ZIP into the Maven repository at 'org/modeshape/jbossas/jbossas-{version}-jbossas-7-dist.zip')

and into the "modeshape-distribution" module, which is where the binary and source distributions

are assembled. And the assembly descriptor was moved to the "modeshape-assembly-descriptors"

module (again, where the other assembly descriptors are managed and installed into the Maven repository).

Fifthly, new integration tests were written to verify that EJBs (of various flavors) can

find the ModeShape repositories correctly using the 4 different ways of looking up a repository:

1) looking up a repository in JNDI

2) looking up the Repositories interface and using it to get a named repository

3) using RepositoryFactory with a single URL (e.g., "jndi:jcr/sample" or "jndi:jcr?repositoryName=sample")

4) using RepositoryFactory with a URL to the engine (e.g, "jndi:jcr") and the name of the repository

These new integration tests are in a new Maven module that downloads AS7 and the ModeShape kit

from the Maven repository and unpacks them into the 'target' directory. When Surefire runs,

this managed server is started, the Arquillian tests are run, and then the server is shutdown.

Each Arquillian test involves creating a WAR file that will be deployed by Arquillian to the

running server, running the unit tests, and then undeploying the WAR file. The tests

can also be run with a different profile so that the tests are deployed and executed in

a separate server installation (as specified by the $JBOSS_HOME variable).

Finally, the older "modeshape-integration-tests" module and the new "modeshape-jbossas-integration-tests"

were relocated to a new top-level folder called 'integration' in the source code. Like the other

top-level directories in our codebase, this is also a Maven module that can be used to run

all of the integration tests. And the '-Pintegration' profile was brought back so that

the distributions are not created and the integration tests not run during the normal builds.

Thus, to run a normal developer build (with all the unit tests but none of the integration tests) simply use

mvn clean install

while the following command will build everything, run all the unit tests, build the AS7 assembly, and run the integration tests:

mvn clean install -Pintegration

As before, running an 'assembly' build (used for releases) will build everything, run all the unit tests,

build the AS7, binary, and source assemblies (including JavaDoc), run the integration tests, and run

the demos:

mvn clean install -Passembly

  1. … 624 more files in changeset.
'Release: update versions for modeshape-3.0.0.Alpha4'

  1. … 45 more files in changeset.
'Release: update versions for modeshape-2.8.1.Final'

  1. … 70 more files in changeset.
Released ModeShape 3.0.0.Alpha3

  1. … 45 more files in changeset.
MODE-1389 - Updated assemblies and descriptors

  1. … 38 more files in changeset.
MODE-1414 (related): promote version #'s in 2.5.x to 2.5.4.GA for BZ-786561 Roll up patch fro EDS_5.2_20120320

  1. … 68 more files in changeset.
Release: update versions for modeshape-3.0.0.Alpha1

  1. … 45 more files in changeset.
Changed version to SNAPSHOT following release

  1. … 74 more files in changeset.
Changed the '2.8-SNAPSHOT' artifact version to '2.8.1.GA' for use in the product.

  1. … 74 more files in changeset.
'Release: update versions for modeshape-2.8.0.Final'

  1. … 70 more files in changeset.
MODE-1403 Added separate profile for testing with Infinispan 4 and 5 connectors

ISPN 5 uses a newer version of jboss-logging, therefore when this connector is used, some transitive dependencies need to be disabled

MODE-1378 Moved all dependencies to modeshape-parent <dependencyManagement> section

  1. … 37 more files in changeset.
MODE-1398 Added new connector for Infinispan 5

Added a new connector that uses Infinispan 5.x caches for storage. The existing

Infinispan 4.x connector is still usable, and basically users would choose between

the two. Note that Infinispan 5.1.1.Final is likely to be used by JBoss AS 7.1.0.Final.

All unit and integration tests pass.

  1. … 33 more files in changeset.
'Release: update versions for modeshape-3.0.0.Alpha1'

  1. … 43 more files in changeset.
Changed version to 2.8-SNAPSHOT after releasing 2.7.0.Final

  1. … 73 more files in changeset.
'Release: update versions for modeshape-2.7.0.Final'

  1. … 76 more files in changeset.
MODE-1353: promote version #'s in 2.5.x to 2.5.3.GA for SOA-3656

  1. … 68 more files in changeset.
Changed versions to prepare for 2.7-SNAPSHOT development

  1. … 77 more files in changeset.
'Release: update versions for modeshape-2.6.0.Final'

  1. … 69 more files in changeset.
Changed version to 2.5.2.GA, in preparation for release.

  1. … 73 more files in changeset.
Downgraded Hibernate version to 3.4.0.GA so that it doesn't depend on JPA 2

  1. … 4 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'

  1. … 447 more files in changeset.
'Release: update versions for modeshape-2.6.0.Beta2'

  1. … 69 more files in changeset.
'Release: update versions for modeshape-2.6.0.Beta1'

  1. … 69 more files in changeset.
Changed versions in POMs to '2.5.1.GA'

  1. … 65 more files in changeset.
Changed versions in POMs to '2.6-SNAPSHOT'

  1. … 65 more files in changeset.