With CMCC major version 10 (1907), the Blueprint workspace has been restructured in order to support independent development of each CoreMedia application.

Up to CM9 (1904), the Blueprint workspace was monilithic in the sense that it is not possible to build only parts of the workspace. Even opening a workspace sub-folder in an IDE is not possible in a meaningful way.

Since the strongest possible technical separation of code is in which application it is used, the new workspace consists of several workspaces that can be built independently. Each application runs in its own process (usually a JVM) and as such manages its own third-party library versions. The applications are Content Server (including its flavors "management", "master live" and "replication live"), Workflow Server, Studio Server (REST backend), Studio Client, two Studio auxilliary services (User Changes and Packages Proxy), CAE ("preview" and "live"), CAE Feeder ("preview" and "live"), Content Feeder, Solr, Headless Server (part of the product since 1907), Elastic Worker, and the deprecated Site Manager. In addition, there are workspaces containing resources: Frontend (templates, themes, bricks) and (demo) Content.

There are workspaces containing shared code that have to be built before the application workspaces that use this shared code. The most basic workspace, "Common", contains code shared by Content Server, Workflow Server, and Studio Packages Proxy. On top of that, the "Middle" workspace bundles shared code used by all middle tier servers or applications, namely Studio Server, User Changes, CAE, CAE Feeder, Content Feeder, Headless Server, Elastic Worker, and Site Manager. Solr, Studio Client, Content and Frontend do not use any shared code at all.

After both shared workspaces have been built, any application workspace can be built and opened in an IDE independently. As a project developer, you can focus on one application. Changes to shared code must be performed with extra care, and now you can easily see whether the code you change is application-specific or shared.

Sorting all Maven modules by their usage in applications results in a workspace structure where compared to CM9, every single module is located under a new, different path. However, the contents of these modules did not change at all, at least not for the sake of modularisation. To migrate a CM9 workspace to CMCC 10, in most cases, merging via Git should work, but be prepared for conflicts in Maven POMs. For other VCSs, a mapping from old to new module paths will be provided.

Upgrading the Blueprint workspace

Before upgrading to 1907 you should first upgrade to the 1904.2 tag of your CMS-9 or LC3 product. For CMCC-10 we merged all the different product branches into one and created a git history that allows you to merge the 1907.1 blueprint onto your 1904.2 blueprint.

(CMS-14747)