/
Module Lifecycle

Module Lifecycle

Owned by Rod Widdowson
Last updated: Apr 07, 2025
2 min read

This document spring from IDP-2160: We should stop depending on plugins saying what modules they need to disable.Open during which is became clear that the lifecycle of modules, particularly plugin-supplied is quite subtle.

During IdP Install and Update

  • We only do things with modules list in the NEW IdP Installation

    • In particular plugin generated modules are not touched (enabled or disabled)

    • We only look at the currently installed plugins to make sure they support the new version

  • Any ‘core’ modules are not enabled in the old install are installed early on during the install/upgrade

    • The core modules are currently idp.Core,idp.EditWebApp and idp.CommandLine

  • At a later stage all the modules (found in the NEW installation source) which were enabled (in the being-updated distribution) are re-enabled.

  • The old install’s concept of what modules exist is not looked at at any time

Plugin Install/Update/Remove

This is more complicated - we look at both the existing plugin version’s (if there is one) idea about modules as well as the new one.

Plugin Install

All modules in the getEnableOnInstall list (of the new plugin) are enabled.

Plugin Update

  1. We get a list of all currently enabled modules from the existing install.

  2. We call the new plugin at getEnableOnInstall to get a list of what modules to install

    • Then we enable, or re-enable them

  3. At a later stage we ask the new plugin about modules it supports

    1. And if it was initially enabled (captured at stage 1) but not enabled in stage 2 we re-enable them

Plugin Uninstall

The plugin is consulted at getDisableOnRemoval and those modules are disabled.

Note: modules which are parented by this plugin but are not on the getDisableOnRemoval list, are not disabled.

 

Related content