close

Filter

Close X
loading table of contents...

Release Notes / Version 10.2101

Table Of Contents

Modularization of Project Extensions

With modularization of the CoreMedia Blueprint workspace, project extensions have undergone a structural change, too.

The goal of this build configuration refactoring is to keep the modular workspaces structure of CoreMedia Blueprint. It must be possible to build each application workspace independent of other application workspaces. Extensions that aggregate modules that (conceptually) belong to different workspace would prevent such modular builds.

All bundled extensions that used to reside under modules/extensions have been distributed over the modular workspaces they extend. Each workspace has its own modules/extensions directory and Maven aggregator.

Each extension point belongs to exactly one workspace, so an extension module plugging into such an extension point belongs to the same workspace. Extensions may also have shared code, which then becomes part of a shared workspace (usually shared/middle , otherwise shared/common ).

For backwards-compatibility and for special use cases like reusing extensions from another repository, it is still possible to keep an extension with all its workspace-specific parts in the central location modules/extensions . However, a few changes are necessary to make such extensions work in a CMCC 10 Blueprint workspace.

To migrate a CMS 9 / LC 3 project extension to CMCC 10 (1907+)

  1. The extension must reside in a directory named like the extension, below the top-level path modules/extensions . It may be nested in another directory for grouping multiple extensions, but such intermediate directories must not contain a pom.xml file.

  2. The extension must consist of one root Maven project that aggregates its workspace-specific parts. This POM may neither contain any other configuration nor be used as a parent, because it will only be read by the CoreMedia Extension Tool and must not be part of the Maven reactor.

  3. For each extension part, the CoreMedia Extension Tool must be able to determine the workspace this extension part belongs to. There are three heuristics to find out the workspace:

    1. The extension part uses com.coremedia.blueprint:<workspace>.extensions as its parent, where <workspace> is one of the modular apps- or shared-workspaces like cae , studio-server , studio-client or middle .

    2. The extension part itself uses an extension point. Then, the extension part is assigned to the workspace of the extension point.

    3. The relative path from the extension's root to the extension part resembles the path of a modular workspace ( apps/cae , apps/studio-client , shared/middle ). This is recommended, but not required if any other heuristic matches, because it resembles the modular workspace paths you should get used to, anyway.

This means that the main work when migrating your extension is to change the POM parents of your first-level extension modules to the corresponding modular workspace extensions aggregators (or remove the <parent> element completely and use one of the other two heuristics to let the tool determine the target workspace). When replacing or removing your former parent, its configuration is no longer available. If that configuration consists of dependency management, you should check whether it is still needed (the new parent inherits a lot of dependency management from the workspace's blueprint-parent) and if so, whether it is shared between extension parts. If it is indeed shared, you must move it to a new module that acts as a BOM (bill of material) and depend on this new module with <scope>import</scope> wherever needed.

You must copy all other configuration to all extension parts that need it. More often than not, "shared" configuration is not actually needed by all modules that inherit this configuration.

After this POM structure refactoring has been applied, it should be possible to run the CoreMedia Extension Tool to add your migrated (but still "centralized") extension to all affected workspaces. The command line is the same as for "distributed" extensions (like the bundled extensions) as given in the Blueprint Developer Manual:

mvn -f workspace-configuration/extensions extensions:sync -Denable=<name-of-your-extension>

In Blueprint version 1907.1, the preconfigured Extension Tool version is outdated, so please change the version in workspace-configuration/extensions/pom.xml or add it on the command line to use the latest release (4.0.1 as of this writing): 

mvn -f workspace-configuration/extensions com.coremedia.maven:extensions-maven-plugin:LATEST:sync -Denable=<name-of-your-extension>

To check that your extension has been enabled successfully, follow the step-by-step instructions in Blueprint Developer Manual, section "Implementing a Custom Extension".

(CMS-15943)

Search Results

Table Of Contents