CoreMedia Digital Experience Platform 8 Developer Manual, Version 7.5.45-10
3.3. Configuration of the CoreMedia Workspace | 3.3.3. Configuring the Workspace

The Blueprint workspace comes ready to use. However, there are some environment specific configurations to be adjusted at the very beginning of a project. You may skip these steps only if you are just going to explore the workspace, you will neither share your work with others nor release it, and you will start over from scratch again with your actual project.

Changing the groupIds

The groupId of the CoreMedia Blueprint workspace is com.coremedia.blueprint. While this works from the technical point of view, you have to change it to a project specific groupId, because CoreMedia reserves the possibility to provide versioned artifacts of this groupId.

Since the groupId is needed to denote the parent POM file, it cannot be inherited but occurs in every pom.xml file. You can simply globally replace all occurrences of <groupId>com.coremedia.blueprint</groupId> in Blueprint workspace pom.xml files with your project groupId.

Selecting deployment repositories

Only the artifacts below the $CM8_BLUEPRINT_HOME/modules hierarchy will be deployed to a Maven repository. See Section 4.2.1, “Performing a Release” for a deeper introduction in releasing and deploying artifacts.

To configure the repository URL to deploy the artifacts to, you need to adapt the distributionManagement section of the root pom.xml and all BOM pom.xml files of the extensions, for example:

CoreMedia strongly advises you to use a repository manager.

Using a Version Control System

The CoreMedia Blueprint workspace is developed and maintained in a Git repository, therefore the root pom.xml contains references to a CoreMedia internal repository in the scm tag. You need to replace this setting with your own source control URL in order to perform a release. Please refer to existing Maven documentation for details.

Change line endings (optional)

The Blueprint workspace is delivered in UNIX format (line breaks). Depending on your local setup it might be required to change the line endings to DOS format (carriage return and line break).

Configuring the licenses

Currently, there are several ways to configure license files in the workspace required for the Content Servers:

These approaches are described in the next sections. The license files are delivered in a Zip file. Unpack the file to get three further Zip files. The name of the files follows this scheme:

<Version>_CoreMedia_AG_<ServerType>_DATA_<UniqueCode>_license.zip

The server type abbreviation has the following meaning:

Copying license files to source tree

Copying the license files to your source tree is the simplest and most straightforward approach. It can be achieved by simply copying the Zip files to the appropriate locations and rename them to license.zip:

Using a license profile

If you want to use the profile approach, you need a repository manager (see the section called “Additional Software”) for your project to provide the license artifacts via a secured internal repository.

The license artifacts must be of type war and the license should be packaged at WEB-INF/properties/corem/license.zip within the artifact. You should deploy the artifact with a custom groupId and custom release version (not a snapshot version) and should not use the values predefined in the workspace. The classifiers production, publication and replication refer to the type of the license and you can either keep it this way or use different GAV (GroupId, ArtifactId, Version) coordinates to distinguish the license type.

The default workspace profiles internal-licenses are defined in the files:

and look like the following snippet:

<profile>
  <id>internal-licenses</id>
  <dependencies>
    <dependency>
      <groupId>YOUR PROJECTS GROUP ID</groupId>
      <artifactId>development-license</artifactId>
      <version>A RELEASE VERSION</version>
      <type>war</type>
      <classifier>production</classifier>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</profile>

The profile approach has the advantage that you can define two profile types, one for development licenses and one for production licenses, if you want to deploy the license together with the artifact.

Configuring licenses for deployment

You can use different approaches for providing development and production licenses. It would be sensible, for instance to provide your production license files only as file system resources on production servers while you still provide development licenses with both approaches described before.

For production licenses as file system resources, you can configure the license location using one of the filtering approaches described in Section 4.3.9, “Configure Filtering in the Workspace”.

Using the preconfiguration approach, you need to configure CMS_LICENSE, MLS_LICENSE and RLS_LICENSE in the packages/src/main/filters/preconfigure.properties

Using the post-configuration approach, you need to configure the properties in the files on the target machine, for instance

Chef configuration

To configure the license locations for the Chef provisioning run, you need to override the default attribute. For a chef only setup, this can be done in the role executing the server recipe, for example in the file boxes/chef/vagrant-chef-repo/roles/management.rb you need to add an entry to the override_attributes map :

"override_attributes" => {
  "coremedia" => {
    "configuration" => {
      "configure.CMS_LICENSE" => "/opt/coremedia/cms-license.zip"
    }
  }
}

For development purposes with Vagrant, you can provide the license via one of the shared folders for example boxes/target/rpm-repo and set the configuration attribute in the chef.json hash in the Vagrantfile. Simply apply to it the same coremedia hash shown in the listing above.