Clone Tools
  • last updated a few minutes ago
Constraints: committers
Constraints: files
Constraints: dates
Changed POM version to '3.0.1-SNAPSHOT'

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

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

  1. … 54 more files in changeset.
MODE-1675 - Changed the build so that modeshape-client.jar is a publishable artifact during the "assembly" profile

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

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

  1. … 54 more files in changeset.
MODE-1563 - Added JCR integration for the initial import handler

  1. … 22 more files in changeset.
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.