Packaging, Deploying, and Versioning BAR Files
Packaging, deploying, and versioning BAR files
This domain tests how ACE artifacts become a deployable BAR and how versions are promoted. A BAR is the deployment unit containing compiled message flows, maps, ESQL, XSLT, DFDL schemas, Java, and related resources. Applications and libraries organize those resources; shared libraries are referenced rather than copied into every BAR.
Core rules
- An application is the deployable unit that can contain flows, maps, and libraries. A shared library is deployed separately and referenced by applications; a static library is packaged into the application.
- Include all runtime dependencies in the BAR or ensure referenced shared libraries are already deployed. Missing dependencies fail at deploy or first use.
- Use configurable properties and policy overrides for environment-specific values. The same BAR should move from test to production with different overrides.
- Version with source control and clear application or BAR naming. Do not rely on overwriting a BAR as your only version history.
- Build and deploy through a repeatable pipeline command or the Toolkit, then verify deployment status and event-log messages.
Worked example
An application uses a shared library for common error handling and a static library for a map. Build the BAR with the application and the static library included; deploy the shared library first, then the application. Apply a policy override for the production endpoint. If deployment fails, check that the shared library version referenced by the application matches the one deployed and that all Java or DFDL dependencies are present.
Traps
Packaging a shared library into every application duplicates it and creates version drift. Deploying an application before its shared library causes resolution failures. Rebuilding for each environment defeats promotion. Keeping only the latest BAR loses rollback capability.