The Basic Checklist

How Checklists are Discovered

OakPAL Checklists are discovered by scanning MANIFEST.MF files on the classpath for Oakpal-Checklist headers, which each define a comma-separated lists of JAR-relative resource paths. The MANIFEST.MF should also use a Bundle-SymbolicName or Automatic-Module-Name header to declare a module name for its exported checklists.

For example, the oakpal-core jar exports a single checklist, OAKPAL-INF/checklists/basic.json checklist, and identifies itself as net.adamcin.oakpal.core, in META-INF/MANIFEST.MF.

Discovered checklists are referenceable by module/name, as in net.adamcin.oakpal.core/basic, or for shorthand, just name, as in basic. Shorthand is matched according to the order of checklist discovery on the classpath.

The Structure of a Checklist

Checklists are json files that match the basic structure of this example:

{
    "name": "acmeAemChecks",
    "checks": [
        {
            "name": "require-acme-metadata",
            "impl": "com.example.acme.oakpal.checks.RequireAcmeMetadataCheck"
        },
        {
            "name": "OSGi Configs Check",
            "impl": "com.example.acme.oakpal.checks.OsgiConfigsProgressCheckFactory",
            "config": {
                "installerPaths": ["/libs","/apps"]
            }
        },
        {
            "name": "No embedded clientlibs",
            "impl": "OAKPAL-INF/checks/noClientLibEmbed.js",
            "config": {
                "allow": true,
                "boo": false
            }
        }
    ],
    "repoInits": [
        "create path (nt:folder) /apps",
        "create path (nt:folder) /libs"
    ],
    "forcedRoots: [
        {
            "path": "/content/acme",
            "primaryType": "sling:Folder",
            "mixinTypes": []
        }
    ],
    "jcrNodetypes": {
        "sling:ResourceSuperType": {
            "@":[
                "mixin"
            ],
            "-":[{
                "name":"sling:resourceSuperType",
                "type":"String"
            }]
        }
    },
    "jcrPrivileges": [
        "acme:distributeRedditGold"
    ],
    "jcrNamespaces": [
        {
            "prefix": "sling",
            "uri": "http://sling.apache.org/jcr/sling/1.0"
        }
    ]
}

A checklist basically has a name and a list of checks, which represent CheckSpecs. Each check spec must have at least a name, and an impl representing a className of a ProgressCheckFactory or ProgressCheck implementation, or a classpath resource name to locate a script progress check. For script checks and ProgressCheckFactory implementations, you can specify an optional config object to serve as a default configuration when this check spec is loaded.

For a real example, refer to the the basic checklist.

A checklist may also specify a few optional properties that the OakMachine can load before each scan as an InitStage. When the checklist is actively selected in the maven plugin, these resources will be used to to initialize the repository to a state that serves as a starting context for checks. They will be applied in the order they are listed below.

cndNames

Specify an array of CND (compact nodetype definition) files that should be installed in the repository prior to the scan. These can be either absolute (identified as containing a colon :), or relative to the root of jar containing the checklist.

cndUrls

Specify an array of URLs to CND (compact nodetype definition) files that should be installed in the repository prior to the scan. These are always assumed to be absolute URLs, and an element will be ignored if an exception is thrown by new java.net.URL(element).

jcrNamespaces

Specify a list of JCR namespace prefix-to-uri mappings in order to register new ones, or to remap a registered namespace to a different prefix in the scan session.

jcrNodetypes

Register a set of node types to support creation of forced roots prior to the scan.

jcrPrivileges

Register a list of JCR privileges to support the installation of rep:policy nodes that reference them. This can be either a list of strings, each interpreted as a non-abstract, non-aggregate privilege, or an object, where each key is interpreted as a privilege name, and the associated value is an object in the form of { "abstract": boolean, "aggregateNames": [ ... ] }.

forcedRoots

Specify a list of root paths to create (akin to using mkdir -p), and optionally specify a primary type and/or a list of mixin types to apply to the leaf node. Intermediate paths will be created as nt:unstructured nodes.

repoInits

Specify a list of zero or more inline repoinit scripts, which are ultimately concatenated and evaluated together as a single repoinit script. See The 'repoinit' Repository Initialization Language.