close

Filter

Close X
loading table of contents...

Release Notes / Version 10.2101

Table Of Contents

CoreMedia Workspace

Blueprint Workspace Upgrade from 1904 to 1907

Because of the new modular workspace structure, almost every single file has been moved to a new location between 1904 (LC3, CMS9) and 1907 (CMCC 10), and the four product flavors (three LC3 variants plus "plain" CMS) have been merged into one workspace. The migration process to 1907 is best done by using the Blueprint Workspaces Git repository provided by CoreMedia on GitHub. Additionally, because Git's rename detection results in too many false positives in this case, CoreMedia provides a script that moves all files to their 1907 locations when applicable. Prepared like this, you should be able to merge in cmcc-10-1907.3 and only see "real" conflicts, which you must resolve. After that, take care of upgrading your custom extensions, as described in CMS - 15943, "Modularization of Project Extensions".

Here are step-by-step instructions how to upgrade your Blueprint workspace to CMCC 10 1907.3. You will find the commits which are mentioned below at https://github.com/coremedia-contributions/coremedia-blueprints-workspace/commits/cmcc-10-1907.3 . Be aware that during the intermediate steps the workspace might not be buildable.

1. Change your groupId and version back to "com.coremedia.blueprint" and "1-SNAPSHOT" to prevent unnecessary conflicts

2. Update to 1904.3. Depending on the product you started from, the corresponding tag in the Blueprint Git repository is "cms-9-1904.3", "livecontext-3-for-sap-hybris-1904.3", "livecontext-3-for-salesforce-commerce-cloud-1904.3", or "livecontext-3-for-ibm-wcs-1904.3".

3. Merge the "Merge all 1904 products" commit (which is the parent of the "move files to 1907 locations" commit below)

git merge bc09b1afd8b2c850fbaeffb444763f6857911665

4. Apply move script

4.1. Get the script:

curl -o /tmp/move-1904.3-to-1907.3.groovy https://releases.coremedia.com/cmcc-10/artifacts/1907.3/move-1904.3-to-1907.3.groovy

4.2. Execute the script:

mvn org.codehaus.gmaven:groovy-maven-plugin:2.1:execute -Dsource="/tmp/move-1904.3-to-1907.3.groovy" -Ddir=$(pwd) --non-recursive

4.3. Commit the changes

git add .
git commit -m "move 1904 to 1907 structure via script"

5. Ignore the "move files to 1907 locations" commit (you have already moved everything using the script)

git merge -s ours 9f0faa2a776294db4b614483287b370370185632

6. Disable Git rename detection Change your diff & merge sections in ~/.gitconfig as follows:

[diff]
    renames = false
    ...
[merge]
    renames = false
    ...

7. Merge the 1907.3 "automatic update commit"

git merge cmcc-10-1907.3

8. Resolve conflicts and commit

9. Enable Git rename detection again

10. Change back to your groupId and version

Upgrade Integration

When you continue development on 1904.3 on a separate branch while performing the upgrade to 1907.3, you probably want to integrate the upgraded branch with your development branch eventually. To do this you have to perform basically the same steps as for the original upgrade but instead of merging from the CoreMedia upstream you will merge from your upgrade branch. These are the steps that change:

3. Instead of merging commit "Merge all 1904 products" from the CoreMedia upstream, merge the commit that you created during the upgrade, which merges commit "Merge all 1904 products".

5. This step can be skipped, as the original move-commit has been ignored already.

7. Instead of merging tag "cmcc-10-1907.3", merge the commit that you created during the upgrade, which merges tag "cmcc-10-1907.3".

11. It should now be possible to merge all the changes you made after the upgrade onto your development branch normally.

Known Issues

Modules that no longer exist in 1907, like modules/extensions/ecommerce-sfcc/lc-ecommerce-sfcc-cae-lib, may be moved by the move-script to locations that do not make sense (for the example: although a CAE module, it ends up under content/!). However, this does not matter, because by merging the "automatic update to 1907" commit, these modules will be deleted. You will only get conflicts (theirs: deleted, yours: modified) if you made changes to these modules, but then you will have to invest special efforts into keeping your adapted version of LC implementations that officially no longer exist in 1907, anyway.

(CMS-16303)

Extensions Tool Update

The CoreMedia Extensions Tool has been updated from version 3.0.0 to version 4.0.1. This version can and should also be used for 1907.1 by manually updating the version number in workspace-configuration/extensions/pom.xml and then running the extension tool's sync command: 

mvn -f workspace-configuration/extensions extensions:sync

The structure of the Blueprint workspace in 1907.2 has been adapted slightly, but the tool "migrates" a 1907.1 workspace to the new structure automatically, so this is not a breaking change.

The tool has been fixed and its usage has been simplified. The Blueprint Developer Manual has been updated accordingly, see sections 4.1.5, "Project Extensions" and 4.4.2, "Developing with Extensions".

Here are the new features and fixed bugs:

  • There are new configurations for the path where extensions and extension points are located in any workspace or globally, called extensionsPath and extensionPointsPath . This was the basis to simplify and fix the tool.

  • The tool now handles extension modules in shared workspaces.

  • It also now manages test-jars, ignoring which led to problems when disabling certain extensions (see CMS_15892).

  • Adding, enabling, disabling and removing extensions has been simplified. There no longer is a distinction between disabled and removed extensions. To add a new extension, it just has to be placed at the right locations and enabled (see Blueprint Developer Manual, updated sub-section "Implementing a Custom Extension"). Thus, the option addProjects is obsolete and has been removed. When disabling an extension, all references to it are removed from extension point dependencies, extensions aggregators, and the extensions BOMs. The remove goal has been re-interpreted to delete all files of the given extensions even without the prune flag. The prune flag still exists, but only matters in combination with a given extensionsFile .

  • Centralized extensions are now also added to the corresponding workspace extensions aggregators. Previously, centralized extensions prevented modular building of separate Blueprint workspaces, because they caused circular dependencies between the extension aggregator (affecting multiple workspaces) and the affected workspaces (depending on parts of the extension). Now, centralized extension are only placed at a central location, but still their parts are added to the workspace they extend. Thus, the modular workspaces can still be built in their dependency order (shared/* first, then any apps/* workspace), as described in the Blueprint Developer Manual.

  • Extensions BOMs are now one-per-workspace, not one-per-extension-point. This makes more sense, since one workspace only has one common dependency management, which is now split up into a manually maintained part ( workspace -blueprint-bom ) and a part managed by the extensions tool ( workspace -extensions-bom ). This obsoletes the two additional extension point BOMs preview-cae-extensions-bom and studio-client-dynamic-extensions-bom . When the tool migrates a 1907.1 workspace, it will empty those two BOMs, but not delete them. When you merge with the 1907.2 Blueprint workspace files, these two BOMs will be deleted by CoreMedia, which you can accept, unless you referenced them in your own customizations.

  • Extension dependencies are now checked by the tool to prevent inconsistent states in the first place, before you run into build or run-time issues.

  • The verbose output of the list command has been improved to print the modular workspaces structure of each extension, and can now also list details about one specific extension given as -Dextension=... .

(CMS-15922)

Search Results

Table Of Contents