Blueprint Developer Manual / 4.3 Build and Run the Applications

Blueprint Developer Manual / Version 2107

4.3 Build and Run the Applications

The Blueprint workspace provides Maven modules to build Spring Boot applications for Blueprint applications.

Prerequisites

Before you can run the applications, you have to build the CoreMedia Blueprint Workspace in advance:

mvn clean install -Pwith-docker

See Section 3.2.1, “Building the Workspace” for more details.

Workspace Structure

apps/<app-name>/spring-boot - below this folder there is a Maven module for each service application. Each of these modules will build a single Spring Boot application packaged as a JAR file.
shared/common/spring-boot/blueprint-spring-boot-autoconfigure, this module encapsulates common configuration aspects for all Spring Boot service modules.

See Section 4.1.4, “Structure of the Workspace” for more details.

Application Structure

Each Spring Boot application module is structured the same way:

A source folder containing at least the application starter class. It could also contain other classes implementing Spring configuration classes.
A resources folder containing the properties files and the logging configuration file.

Spring Configuration

Each application can define properties in multiple Spring Boot profiles:

The default profiles with properties defined in application.properties.
The development profiles defined in application-dev*.properties.
The local profiles with properties defined in application-.*-local.properties. These properties can contain paths only available on a local workstation. The default local profile is named local and should be used when starting the application using either IDEA or Maven.

The Docker specific Spring Boot profiles can be found under apps/<app-name>/docker/src/docker/config, like

Commerce specific settings:
- application-dev-wcs.properties
Development profiles activating development features for local and CI environments.
- The default development profile is named dev and should be used when starting the application using either IDEA or Maven.

Logging

The overall logging setup is configured in the configuration files logback-common.xml and logback-elk.xml located in the module blueprint-spring-boot-autoconfigure. Note that these files are declared as included and must be referenced in the concrete logback-spring.xml file of each application. This way, every application can configure its own default log level and appenders.

Developing with CoreMedia Blueprint applications

Currently there are two different approaches to start the Spring Boot apps you want to develop locally:

using the spring-boot-maven-plugin
using IntelliJ IDEA run configurations together with the Run Dashboard

The apps you don’t want to alter, can be provided using either:

a remote deployment of any kind using the Spring Boot apps, that is Docker or Chef.
a local Docker deployment for complete isolation or running offline.

Application Configuration Facade

To configure the locally started applications, Spring Boot profiles are being used:

dev - this profile activates development features like actuators, monitoring etc. and should not add filesystem or localhost features. This profile will be active by default if you include the development.yml in the docker compose setup included with this workspace.
local - this profile configures local paths within the workspace like paths to licenses or source folders of other modules. This profile should only be activated for locally started apps using Maven or IDEA but not the docker compose setup.

To configure which application should be used from a remote system, there is a list of convenience host properties, forming a simple configuration facade. The intent of these properties is to use them only on the command-line or in IDEA run configurations when you are developing locally. Do not use these properties outside of the application-local.properties files.

The main property is installation.host which when set implicates all other services / endpoints are running remotely. By default, all other convenience host properties derive their default from installation.host. If you start more than one service locally, lets say studio-server and preview, then you need to tell studio-server to use the locally started preview instead of a remote one and you have to set cae-preview.host to localhost.

- installation.host
    |- db.host
    |- mongodb.host
    |- solr.host
    |- content-management-server.host
    |- master-live-server.host
    |- workflow-server.host
    |- cae-preview.host
    |- cae-live.host
    `- wcs.host

Search Results

Table Of Contents

Filter