This article covers a Bloomreach Experience Manager version 11. There's an updated version available that covers our most recent release.

Using the hippo-cms7-release pom for Hippo CMS projects


The hippo-cms7-release master pom defines all standard Hippo CMS product artifacts dependencies in the correct combination of versions representing an officially endorsed and supported Hippo CMS7 release. This makes it much easier to setup and maintain your custom Hippo CMS project  and keep it up to date with newer versions. For each officially endorsed and supported Hippo CMS release a corresponding updated version of the hippo-cms7-release pom will be made available through the Hippo maven repository, e.g. 


Features of the hippo-cms7-release pom

The hippo-cms7-release pom provides the following important sections and meta data definitions:

Standardized Hippo CMS product version properties

The properties section of the hippo-cms7-release pom defines a version property for each standard Hippo CMS product:


These version properties are used in the subsequent dependency management section to ensure all Hippo CMS7 product specific artifacts are defined using the same version. Furthermore, this specific combination of Hippo CMS7 products versions together constitute the officially endorsed and supported Hippo CMS7 release depicted by this hippo-cms7-release pom. This doesn't mean other version combinations are not allowed or supported, but such other combinations might be less, or not at all, validated by Hippo itself, unless explicitly stated otherwise.

If there is a need however to override to a (usually newer) other version of a specific Hippo CMS7 product, these property definitions come in very handy. If your custom Hippo CMS7 maven project extends from the hippo-cms7-release pom, you only need to override/redefine one of these standardized properties in your local maven project like:

    <!-- temporary override to the latest and greatest under
         development version of HST -->

That's it. No further changes should be needed nor desired! If at a later time a newer version of the hippo-cms7-release pom becomes available with the product version you used in the override (or newer), you only have to upgrade to the newer hippo-cms7-release pom and remove the temporary version override for the specific product. By just looking at a custom Hippo CMS7 project's (main) property definitions, it will be very easy to see if a custom combination/override of Hippo CMS products is used, or not.

Note: As can be seen from the above example properties, the hippo-cms7-release pom defines both the main (core) Hippo CMS products as well as a Hippo certified CMS and/or site plugins.

Standard Maven repositories

The hippo-cms7-release pom defines additional useful Maven repositories for your convenience, such as for example the Hippo forge repository that hosts CMS and/or site plugins. For the certified Hippo CMS artifacts you will not need to define additional Maven repositories, other than the obligatory standard Hippo maven repository for the hippo-cms7-release pom itself.

Dependency management for all Hippo CMS product artifacts and additional certified artifacts

The dependency management section of the hippo-cms7-release pom defines all artifacts from each Hippo CMS product as specified by their version in the properties section (see above). This really is, or should be, the complete set of available artifacts for a specific version, including those artifacts which (typically) are only needed or used by Hippo internally like for testing purposes. If you need a specific artifact dependency in your custom Hippo CMS project, you can and may copy/paste its definition from the hippo-cms7-release pom. However: do not change the <version> element for the dependency, but better yet: remove the <version> element all together (thereby automatically inheriting from the dependency management configuration from the hippo-cms7-release pom).

A concrete Hippo CMS product artifact dependency should be (version) "managed" only through the hippo-cms7-release pom, which should only be overridden through a overriding version property definition override as described above. Only include those artifact dependencies in your project which you actually use so that it remains clear which (Hippo CMS or otherwise) products and features your project depends on. If you no longer use or need a specific dependency, remove it!

Inheriting from hippo-cms7-project parent pom

The hippo-cms7-release pom itself inherits from the hippo-cms7-project parent pom, which also is used as parent pom by all (standard) Hippo CMS products. Therefore when you use the hippo-cms7-release pom as parent, you'll also inherit the Maven meta definitions from the hippo-cms7-project pom! The hippo-cms7-project pom provides a set of minimum required and/or convenient definitions also used and needed for each individual Hippo CMS product. Examples are the minimum supported Maven version and Java version, validated/proved working versions of several Maven plugins, etc. And, as master pom for all Hippo CMS products, it also defines the (default) license (ASL2), company info (Hippo), Hippo developers info, etc. Not all these definitions will be required or desired by custom projects extending from the hippo-cms7-release pom. When you inherit from the hippo-cms7-release pom for your custom CMS project, take specific note of the following standard Maven pom elements and fill them in according to your own project requirements or "reset" them by redefining them with empty values:


Note: when you use the Hippo archetype to generate a new custom project the above empty "reset" values will be provided automatically.

Creating a new Hippo CMS project based on the hippo-cms7-releasepom

The easiest way to create a new Hippo CMS project using the hippo-cms7-release pom as parent is using the hippo website archetype. For detailed instructions see the Getting Started Trail.

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?