00. Concepts

IPM Concepts

Lifecycle Phases

Every operation IPM performs on a module, e.g. loading, compiling, testing or publishing, is expressed as a lifecycle phase. When you run a command like load or test, IPM resolves it to an ordered sequence of phases and executes them in turn against the module (and optionally its dependencies).

The lifecycle class for a module type defines a method for each phase. Resource processors attached to the module's resources can also hook into each phase, executing before or after the lifecycle method runs. This separation means the same phase sequence can behave differently depending on what resources a module contains.

Phases run in a fixed order. When you invoke a compound command (e.g. test), IPM resolves it to all the prerequisite phases automatically — you don't need to run them individually.

Default Phases

The canonical order is:

Clean → Initialize → Reload → Validate → ExportData → Compile →
Activate → Document → MakeDeployed → Test → Package → Verify →
Publish → Configure → Unconfigure → ApplyUpdateSteps

Phase	What it does
Clean	Removes the module's resources from the namespace. Recurses into dependencies unless they are required by something else; use -force to remove those too. Modules with <GlobalScope> set to 1 are skipped by default; pass -global to include them.
Initialize	Pulls and compiles module source code from the /preload directory. Used to set up namespace mappings, globals, or other prerequisites before resources are loaded.
Reload	Pulls module source code into the namespace from disk. Does not compile.
Validate	Ensures that the module API section is up to date, that module resource processor attributes are valid, and that the resources exported to the filesystem (and possibly to source control) are consistent with what is in the database.
ExportData	Exports data associated with the module (globals, lookup tables, etc.). Standalone.
Compile	Compiles all resources within the module.
Activate	Performs post-compilation installation/configuration steps: runs projections, activates interoperability productions, etc. Default phase for <FileCopy>.
Document	Regenerates the API documentation for the module. Standalone.
MakeDeployed	Deploys resources within the module for which deployment is enabled (source-stripped form).
Test	Runs any unit tests associated with the module, in the current namespace.
Package	Exports the module's resources and bundles them into a module artifact (.tgz file).
Verify	Installs that artifact in a separate namespace, then runs integration tests (if any).
Publish	Saves that artifact to the repository for which deployment is enabled. Currently, there may only be one of these per namespace.
Configure	Applies configuration that should run after installation — e.g. setting system settings, merging CPF entries. Default phase for <Invoke>.
Unconfigure	Reverses configuration applied by Configure. Runs during uninstall.
ApplyUpdateSteps	Runs migration steps when upgrading from a prior version.

Phase chains

Most commands don't run a single phase in isolation, but rather run a chain of prerequisites first. For example, the test command runs Initialize → Reload → Validate → Compile → Activate → Test. Most of these chains are defined in %IPM.Lifecycle.Base:GetCompletePhasesForOne.

However, some phases invoke others directly in the lifecycle method itself rather than declaring them as prerequisites. For example, Package explicitly calls MakeDeployed, and Publish explicitly calls Package, from within their implementations.

Standalone phases (Clean, ExportData, Document, Configure, Unconfigure) run as-is.

---

Custom Lifecycle Phases

Custom phases let a module expose named operations that aren't part of the standard install/build/test flow. Common use cases:

• A one-off data migration step that should only run when explicitly requested, not on every install.
• Applying a CPF merge only in a specific deployment scenario.
• A developer convenience command (e.g. seed-data, reset-config) that invokes application-specific logic.

Custom phases are not part of any command's default phase chain — they only run when explicitly requested by name.

Custom phases are defined in module.xml using the CustomPhase attribute on <Invoke> or <CPF> elements. See Custom Phase Example in the manifest reference for worked examples.

Running a custom phase

ipm> mymodule custom-phase-name

Custom phases are case-insensitive. IPM resolves them against the phases registered by the module's invokes and resource processors at runtime.