Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
MODE-1639, MODE-1640, MODE-1634 Replaced the Aperture-based MIME type detector with a Tika-based one

This required quite a bit of dependency gymnastics, since Tika has quite a few more transitive

dependencies than the Aperture library (which we had successfully pared down several years ago).

Tika references about 25 dependencies (including transitive dependencies), but this was reduced

in 'modeshape-jcr' to about 8 for basic MIME type detection. Note that Tika usually includes

two BouncyCastle libraries in its dependencies (used for encrypted PDFs, among other things),

but ModeShape intentionally excludes these (as we don't want to ship or depend on any

security-related JARs).

Not only do we get Tika's substantial MIME type database, we've made it possible for users

to edit the 'org/modeshape/custom-mimetypes.xml' file and provide the updated one on the application

classpath. What goes in that file will overwrite all of the other sources (namely Tika's built-in

file and its customization file, both of which are to be found on the classpath), which means

it's easiest to simply provide an updated version of this file at 'org/modeshape/custom-mimetypes.xml'.

Be sure to not remove any of the (few) customizations that ModeShape includes - those are important.

As we upgrade Tika, we'll get updated versions of the media type data. This is far more preferable

than having a ModeShape-specific version.

The MIME type related interfaces in ModeShape's public API (e.g., 'modeshape-jcr-api') have been removed.

These were added sometime in one of the 3.0 releases, so removing them will not introduce compatibility

issues for users.

Instead, we've decided to get out of the MIME type detection framework business, and have decided

to switch to Tika for all MIME type detection. In fact, you can still write your own MIME type detector,

but you do that by implementing Tika's interface and reference the implementation class(es) in the

corresponding service loader file in your JAR. (See the TIKA documentation for details.)

However, internally we still have an abstraction. This is because it is possible to remove the Tika

(and transitive dependencies) from a ModeShape installation, as long as your applications will not

expect any kind of automatic MIME type detection. This is a perfectly valid use case: for example,

using a repository to store data and do not store files (and don't use sequencers).

The AS7 kits required a bit more modification. There is now a new AS7 module for 'org.apache.tika'

that contains all of the JARs, and this is used by the ModeShape module and by the Tika text extractor


All unit and integration tests pass with these changes. Several new tests were added.

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

  1. … 49 more files in changeset.
MODE-1338 Added Teiid Sequencer to JBoss AS kit and distributions

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

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

  1. … 48 more files in changeset.
MODE-1605 Added a kit for AS7.2

The existing resources used in the kit for AS7.1 were changed slightly so that we can have another set of

resources for an AS7.2 kit. The "modeshape-distribution" module now always builds both 7.1 and 7.2 kits,

although by default it only tests the kit for 7.1. To test with 7.2 (which is currently only in Alpha1-SNAPSHOT),

use the "-Pas72" profile.

Verified that all normal builds (no profile, or with the "integration" or "assembly" profiles) pass successfully,

and that they also pass when adding the "as72" profile to these builds.

  1. … 80 more files in changeset.
MODE-1607 Fixed the JavaDoc generation errors due to 'provided' dependencies

After a lot of trial and error (and hangwringing), the easiest solution is to forcibly include the 'provided'

dependencies with a scope of 'compile' in the "assembly" profile in the "modeshape-distribution/pom.xml" file.

Note that we are (and have been for quite some time) building our JavaDoc in one pass, rather than using

aggregate JavaDocs for each module. The reason is that we only want to build the JavaDoc during assembly

builds, and so the aggregate JavaDoc approach results in the JavaDoc assembly running the entire build as

a fork (to build all of the modules _with_ JavaDoc); this means that a full assembly build would build all

modules at least twice. This would make the builds significantly longer, and the Mead productization build

process is not able to even handle such circular builds.

However, if we build the JavaDoc in one pass, then we simply have to have the modeshape-distribution module

depend on all of the other modules for which we want to build JavaDoc and put into the assemblies (e.g., the

distribution, source, and AS7 kit ZIP files). Normally this works great. But this fails as soon as we have

'provided' dependencies that our code references (since the dependencies will be available in the runtime environment);


The solution that works is simply to include the normally 'provided' dependencies in the dependencies list

for the "assembly" profile.

Note that several other changes were made to the profile's definition to clean up the JavaDoc plugin configuration.

  1. … 1 more file in changeset.
'Release: update versions for modeshape-3.0.0.Beta2'

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

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

  1. … 70 more files in changeset.
MODE-1544 - Extracted Tika based mime-type detector and updated the way mime type detectors are loaded and initialized.

Because of the AS7 support, the detectors need to be loaded via the Environment class loader. Also, because text extraction (and implicitly mime-type detection) can be triggered preemptively, some of Tika's excluded dependencies needed to be added back (e.g. for .java and .class files)

  1. … 18 more files in changeset.
MODE-1527 -Added AS7 support for configuring and working with text extractors. To validate the configuration and Arquillian integration test was added as well.

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

  1. … 47 more files in changeset.
MODE-1507 - Updated the AS7 kit to include the WebDav war and also added an Arquillian integration test

  1. … 25 more files in changeset.
MODE-1526 - Added the purge=false attribute to the local caches configuration which preserves the data between restarts. However, this exposes the problem from MODE-1520. To work around this, we're repacking the ISPN main module and we should revert this at some point (MODE-1534)

  1. … 3 more files in changeset.
MODE-1515 - Added Arquillian test for the configured sequencers. In order for all the sequencers to be present in the repository configuration, a workaround with a TODO was added for MODE-1521

  1. … 27 more files in changeset.
MODE-1515 - Extracted AS7 "common" module and fixed the dependencies between modules.

Extracting the common module did bring up a small issue in that i18n resources from other modules (e.g. main) could not be loaded. The reason what that the ClasspathLocalizationRepository always used its own CL to load the .properties file, which doesn't work with the AS7 classloading mechanism. The solution was to simplify the loading and always use the class loader of the i18n class which we're trying to localize.

  1. … 20 more files in changeset.
MODE-1515 - Added a separate AS7 module for each sequencer inside the AS7 distribution kit

  1. … 15 more files in changeset.
MODE-872 - Fixed the AS7 distribution across the integration and assembly profiles

  1. … 2 more files in changeset.
MODE-872 - Updated assembly descriptor & process for modeshape-jdbc

- cleaned up & updated the Ant task which unpacks and processes the dependencies

- added both modeshape-jdbc and modeshape-rest-client to the modules section of the binary distribution

- removed explicit overwrite of maven-ant-plugin from parent pom, as it is defined by jboss-parent

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

  1. … 47 more files in changeset.
Additional cleanup of source distribution and removal of unused files

  1. … 5 more files in changeset.
MODE-1508 Cleaned up dependencies for JBoss AS7 integration

Removed the unnecessary dependencies from the REST service WAR for JBoss AS7, since most of the third-party libraries are now provided by AS7 (including RESTEasy). The assembly was made quite a bit easier, too. Note that the WAR can no longer be tested using Jetty, since Jetty doesn't provide all of the JEE APIs or their implementations.

  1. … 16 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}')

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.
MODE-1389 - Added readme file and included the javax.jcr jar back in the distributions

It seems that jcr-2.0 can be distributed.

  1. … 1 more file in changeset.
Released ModeShape 3.0.0.Alpha3

  1. … 45 more files in changeset.
MODE-1389 - Updated directory for client jar

MODE-1389 - Updated assemblies and descriptors

    • -0
    • +48
  1. … 27 more files in changeset.