-
Notifications
You must be signed in to change notification settings - Fork 183
Code: Java‐based Tooling
In several places across our stack we make use of Java-based tooling such as Saxon and Calabash.
The version of these tools can be pinned using POM files, such as the one present in the build/
directory.
Below is a simple template script that can be used to invoke a Java dependency directly from a POM file.
#!/usr/bin/env bash
# Fail early if an error occurs
set -Eeuo pipefail
if ! [ -x "$(command -v mvn)" ]; then
echo 'Error: Maven (mvn) is not in the PATH, is it installed?' >&2
exit 1
fi
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd)"
OSCAL_DIR="${SCRIPT_DIR}/../../../.." # Edit this to resolve to the OSCAL root from the script's directory
POM_FILE="${OSCAL_DIR}/build/pom.xml"
# Grab any additional files relative to the root OSCAL directory (like stylesheets)
MAIN_CLASS="net.sf.saxon.Transform" #edit this to target your application's main class. below are a few examples:
# XML Calabash: "com.xmlcalabash.drivers.Main"
# Saxon: "net.sf.saxon.Transform"
# Perform any argument processing here, such as preselecting stylesheets in Saxon, etc.
# Note here "${*// /\\ }" is a shell expansion that escapes spaces within arguments.
# For more information, see https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html
ARGS=${*// /\\ }
mvn \
-f "$POM_FILE" \
exec:java \
-Dexec.mainClass="$MAIN_CLASS" \
-Dexec.args="$ARGS"
Note that this template is often extended to parse arguments directly. See an example of this in the profile resolution Saxon wrapper.
This approach has several key advantages:
- The script can refer to resources invariably to the user's current working directory, making it more portable.
- The user does not have to worry about downloading, copying, or otherwise managing any of the Java dependencies.
- A lot of the complexity of consuming stylesheets and other operations can be hidden from the user, making our stack more approachable.
NOTE: This information exists for the benefit of NIST staff. Although the community may reference or inquire about content, this material is not explicitly intended for community support. The community may create issues to report bugs or request enhancements related to this documentation, but there is no support guarantees for this material. All issues will be considered on a case by case basis.
- Contributing to OSCAL Development
- Issue Completeness Review
- OSCAL Patch (Hot Fix) Release Checklist
- OSCAL Release Branching
- Public Events Calendar Management
- Link Check Report Procedure
- Dependency Pull Request Procedure
- Issue Triage and Backlog Refinement
- NIST SP 800-53 OSCAL Content Data Governance
- Workflow for Prototyping a New OSCAL Model
- Backlog Review Process for OSCAL-related Repositories