Build artefacts & content packages
Purpose: Define exactly what ships in a release and the packaging rules that keep installs predictable.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Understanding what a deploy does |
| Platform engineers | Pipeline mechanics |
The release artefact
The archetype's all package: one zip embedding every sub-package in install order:
phi-academy.all-2.14.0.zip
├── ui.apps (/apps code: components, HTL, dialogs, clientlibs)
├── ui.config (OSGi configs per run mode)
├── core bundle (Java, auto-installed via /apps install folder)
└── ui.content (seed /conf structures — filter modes protect authored content)Stored versioned in the artefact repository; the pipeline installs the same zip everywhere.
Filter-mode discipline (the part that bites)
| Package | Path | Mode | Because |
|---|---|---|---|
| ui.apps | /apps/phi-academy | replace | Code is fully owned; leftovers must die |
| ui.config | /apps/phi-academy/osgiconfig | replace | Config drift must die too |
| ui.content | /conf/…/templates seed | merge/update | Authors edit templates/policies at runtime — replace would revert them |
| ui.content | /content seeds | merge, install-once semantics | Never overwrite authored content |
Review filter.xml changes like security changes: a mode flip from merge→replace on a /conf path once deleted a quarter's template work on some team, somewhere, and it doesn't need to be yours.
Rules
- No SNAPSHOT versions past dev; releases are reproducible builds from a tag.
- The bundle version, package version and git tag agree (versioning).
- Third-party bundles ship inside the all package (embedded), pinned — never installed by hand.
- Content migrations ship as separate, explicitly-run packages/scripts with their own review — never hidden inside a code release (rollback strategy).