Configuration Management - Enterprise Java Content management system - Hippo CMS

Configuration Management

Introduction

For version 12, Hippo CMS’s mechanisms for managing the repository data have been significantly redesigned in order to facilitate a great number of improvements for Hippo CMS developers. This includes bootstrapping, base-lining, and separation and migration of configuration and content, both stored in the repository. 

In order to accommodate these improvements in Hippo CMS 12, the previous, XML-based bootstrapping mechanism has been refactored. As of Hippo CMS 12, to-be-bootstrapped configuration and content is specified in YAML 1.1 format. Doing so makes these resources easier to read and maintain.

Pieces of configuration and content are contributed to a Hippo CMS implementation from Hippo CMS’s building blocks (referred to as Hippo CMS), as well as from implementation-specific code. Hippo CMS aggregates them into a merged in-memory model of the configuration, taking into account the specified processing ordering. This results in a Configuration Model, which can then be pushed into the repository, compared to the configuration in the repository, saved, loaded and restored as a baseline configuration, and much more. We can think of this Configuration Model as a controlled version of the configuration.

Table of Contents

Configuration Management

Introduction

For version 12, Hippo CMS’s mechanisms for managing the repository data have been significantly redesigned in order to facilitate a great number of improvements for Hippo CMS developers. This includes bootstrapping, base-lining, and separation and migration of configuration and content, both stored in the repository. 

In order to accommodate these improvements in Hippo CMS 12, the previous, XML-based bootstrapping mechanism has been refactored. As of Hippo CMS 12, to-be-bootstrapped configuration and content is specified in YAML 1.1 format. Doing so makes these resources easier to read and maintain.

Pieces of configuration and content are contributed to a Hippo CMS implementation from Hippo CMS’s building blocks (referred to as Hippo CMS), as well as from implementation-specific code. Hippo CMS aggregates them into a merged in-memory model of the configuration, taking into account the specified processing ordering. This results in a Configuration Model, which can then be pushed into the repository, compared to the configuration in the repository, saved, loaded and restored as a baseline configuration, and much more. We can think of this Configuration Model as a controlled version of the configuration.

Table of Contents