pom.xml

ModeShape 3.x will not need a number of the 2.x modules. In particular:

- since 3.x will only have an AS7 kit, the AS5 or AS6 artifacts were removed

- all the connectors were removed, since they're no longer used

- the connector benchmark tests module was removed, replaced by our new

performance test suite

- the JPA DDL generator utility has been removed

- the 'modeshape-graph', 'modeshape-repository', 'modeshape-search-lucene'

and 'modeshape-clustering' modules have all been removed, since the new

'modeshape-jcr' module no longer uses them

- the DocBook modules were removed and are replaced by the Confluence space

- the two JDBC modules were moved out of the 'utils' directory to top-level modules

The build still works, but not all components have been included in the build.

This is because the query functionality doesn't yet work, so quite a few web

and JDBC driver modules all depend on this.

The assembly profile has not yet been changed or corrected.

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'

Changed the POM and Java source to eliminate the dependency on JCIP annotations. ModeShape

was using only 4 of the annotations (number of corresponding import statements is listed in parentheses):

net.jcip.annotations.GuardedBy (10)

net.jcip.annotations.Immutable (310)

net.jcip.annotations.NotThreadSafe (95)

net.jcip.annotations.ThreadSafe (97)

These were replaced with new annotations in 'org.modeshape.common.annotation' that are semantically

and lexically the same as the JCIP annotations.

The 'net.jcip' dependency was removed from all POMs. This change should be backward compatible.

If user code is explicitly using these annotations within Maven projects, they will have to have explicit

dependencies, and when upgrading to 2.5.0.Beta2 they will not have any issues. Similarly, non-Maven

projects will already have the JCIP JAR on their classpath, and can remove the library if they are not

explicitly using it.

All unit and integration tests continue to pass with these changes.

Created a 'modeshape-parent' project that contains just the information that all other

modules inherit, while leaving the set of modules and module-related profiles in the

top-level build POM. Since almost all of the other projects were inheriting from the

top-level POM, they were changed to reference the new parent (including the new relative

location).

With these changes, the build works as expected. No Java code was harmed or changed.

Prior to this change, someone running a ModeShape build for the first time had to run two separate commands:

'mvn -Pintegration install' and 'mvn -Passembly install'. It also used aggregator goals for JavaDoc and

assemblies, which fork a new build process for each invocation and which can result in a build that does

double work (if they're included in the main build process). Plus, because the JavaDoc and assembly usages

were in the parent POM, the JavaDoc and assemblies were produced before the modules were compiled; on a machine

in which 'mvn install' was not yet run, this caused an error.

Now, the assembly operation is defined in a child module called 'modeshape-distribution' and the assembly

descriptors are referenced as being on the classpath since they're now defined in a new

'modeshape-assembly-descriptors' module. The end result is that, on a fresh machine on which ModeShape

has not yet been built, the source for ModeShape can be downloaded and completely built using a single

command: 'mvn -Passembly install'.

This commit moves quite a few files around and restructures a number of the POM files, but does not affect

any of the Java source code.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2671 76366958-4244-0410-ad5e-bbfabb93f86b

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2476 76366958-4244-0410-ad5e-bbfabb93f86b

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2273 76366958-4244-0410-ad5e-bbfabb93f86b

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.1-dev@2200 76366958-4244-0410-ad5e-bbfabb93f86b

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2198 76366958-4244-0410-ad5e-bbfabb93f86b