The OakPAL Plan

Behind every Oakpal execution there is a plan, even if it is an implicit one.

Prior to release 1.4.0, the plan was tightly-coupled to the oakpal-maven-plugin’s scan and scan-many goals, and was defined by the following parameters:

• preInstallArtifacts: a list of content-package artifacts, resolved by maven, to install prior to the scan. A preInstallFiles parameter is also supported, to reference content package files downloaded or created locally through other means.
• forcedRoots: a list of root paths to create prior to the scan, with optional primary type and mixin types specified for each.
• jcrPrivileges: a list of JCR privilege names to define prior to the scan in order to satisfy named references in rep:privileges properties.
• jcrNamespaces: a list of JCR namespace prefix to URI mappings to register in order to support the included forcedRoots and jcrPrivileges parameters, as well as any dependencies that might be involved in any adhoc checks.
• cndNames: a list of relative paths to CND files located on the scan classpath.
• slingNodeTypes: a boolean specifying (for convenience) whether to install any CND files referenced by Sling-Nodetypes manifest headers in maven dependency jars.
• checklists: the list of reusable checklists to enforce, which must be defined in jar files on the classpath.
• checks: a list of adhoc progress check definitions that may implement new assertions, or override details of checks defined in selected checklists.

The plan definition, importantly, does not include the list of packages that are the subject of the scan.

While it shares many of the same traits as a checklist, the plan has a couple important differences:

• There can be only one plan selected for any particular scan execution, whereas zero-to-many checklists can be active for a particular scan.
• Because of its proximity to the point of execution, the presence of, and alternatives for some plan parameters trade determinism for developer flexibility. Because checklists are designed to be reusable and shareable, scan-time discovery and alternative parameters have been largely disallowed.
• Plans can specify pre-install packages and repoinit URLs, which provide much greater power over the definition of initial repository state, but which carry a lot more overhead that hinders reusability, in the form of download size and lack of visibilty on changes to encapsulated content over time.