Package Manager & content packages
Purpose: Build, install and reason about content packages — the zip files that move repository content between instances.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | The transport mechanism for both code and content |
What a package is
A zip of a repository subtree plus filter definitions. Your Maven build produces one; you can also build them ad hoc at /crx/packmgr.
mypackage.zip
├── jcr_root/apps/phi-academy/… ← the actual tree, as files/XML
└── META-INF/vault/filter.xml ← which paths this package ownsFilters decide everything
| Filter mode | On install |
|---|---|
| replace (default) | Target path is replaced by package content — deletes what is not in the package |
| merge | Adds new nodes, keeps existing |
| update | Updates matching nodes, keeps others |
The classic incident: a package with a broad replace filter on /content wiping authored content. Always review filter.xml before installing anything on a shared instance.
Common operations
| Task | How |
|---|---|
| Export a page tree | packmgr → create package → filter /content/phi/plans → build → download |
| Move content dev→stage | Build & download on source, upload & install on target |
| See what a deploy contained | packmgr → package → coverage/contents |
| Reinstall last known good | Packages are versioned artefacts — keep releases in your artefact repo |
Rules of thumb
- Code packages (from CI) and content packages (ad hoc) should never overlap filters.
- On production, package installation should be pipeline-only; manual installs are break-glass with review.
- Snapshot packages (packmgr keeps one per install) enable quick uninstall — but do not rely on them as backup.