Blueprint Developer Manual / Version 2101
Table Of ContentsThe 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 namedlocal
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 thedevelopment.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