Testing using different NodeStore fixtures

In Jackrabbit Oak unit and integration tests are run using different fixtures which represent configurations of the NodeStore underlying storage for the content repository. This ensures that there is a fixed environment in which tests are run and the results are consistent and repeatable across different runs.

The default fixture used when running mvn clean install is SEGMENT_TAR which uses the SegmentNodeStore with the local storage with TAR files.

To run the tests using a different fixture, you can use the following command: mvn clean install -Dnsfixtures=<FIXTURE>. You can also update the pom.xml file to use a different fixture by updating the fixture property in the oak-parent/pom.xml file. If you want to run using multiple fixtures, provide a comma separated list of fixtures.

These are the possible fixtures that can be used:

• SEGMENT_TAR - Uses the SegmentNodeStore with the local storage with TAR files.
• SEGMENT_AWS - Uses the SegmentNodeStore with the AWS backend.
• SEGMENT_AZURE - Uses the SegmentNodeStore with the Azure backend.
• DOCUMENT_NS - Uses the DocumentNodeStore with MongoDB as the underlying storage engine. This requires a running instance of MongoDB.
• DOCUMENT_RDB - Uses the DocumentNodeStore with the relational databases such as PostgreSQL, MySQL as underlying storage engine. Note that in general, this requires adding JDBC drivers to the class path (see the rdb- profiles in the parent POM), and running the specified database engine in the local network. A notable exception is Derby, which uses the local file system. Also, JDBC URL, user name and password need to be specified as system properties rdb.jdbc-url, rdb.jdbc-user (default: “sa”) and rdb.jdbc-passwd (default: empty).
• DOCUMENT_MEM - Uses the DocumentNodeStore with the in-memory backend. This can be used for running tests that do not require persistence.
• MEMORY_NS - Uses the MemoryNodeStore with the in-memory backend which is more lightweight than DocumentNodeStore but is not as feature-rich.
• COMPOSITE_SEGMENT - Uses the CompositeNodeStore which allows combining multiple underlying segment stores into a single logical repository. It is useful in scenarios where different parts of the content tree have different storage requirements. For example, frequently accessed content can be stored in a high-performance segment store, while less frequently accessed content can be stored in a more cost-effective storage backend.
• COMPOSITE_MEM - Uses the CompositeNodeStore setup which is combining multiple in-memory node stores.
• COW_DOCUMENT - Uses the COWNodeStore setup in which all the changes are stored in a volatile storage.

Note that the Jenkins job that is run as part of the CI flow use both SEGMENT_TAR and DOCUMENT_NS fixtures to run the tests.