CoreMedia Digital Experience Platform 8 Developer Manual, Version 7.5.45-10
3.5. Using the CoreMedia Workspace | 3.5.5. Developing with Components and Boxes

By now, you should have learned how to build the workspace, start the box and optionally how to start the components directly from the workspace. In this section you will learn how to combine both for a nice reproducible development round-trip.

Overview of the Development Infrastructure

The required stack of services and components you need to start before you can start developing with CoreMedia Studio and the Blueprint CAE is considerably large. By using either a common remote development system or the virtualized box, you are being relieved from setting up and maintain those services.

Both options provide their advantages and disadvantages. The common remote environment is saving your developer machines hardware but since it is shared by all developers, it must be highly available and you have to be cautious on updates. The virtualized solution requires a large amount of RAM to be available on your developer machine but it keeps you isolated from other developers and gives you full control to deploy upgrades or control the services.

Development Round-trip using Virtualization

Virtualize intelligently

Before you start your virtualized environment, you should consider, what services you need in order to start your development applications from within your IDE. By default, the virtualized environment will not only contain those requirements, but also the applications you might want to change, such as CoreMedia Studio or CAE. This increases the startup time, the memory and the CPU footprint on your host machine. To decrease these factors, you can decrease the number of services started by choosing a different Chef role to run and then decrease the amount of memory reserved for the box.

To set a different Chef role and reduce the memory footprint, simply add a .vagrantuser file beside the Vagrantfile and apply the following YAML configuration to it:

vm:
  memory: "2048"
chef:
  run_list:
    - "role[base]"
    - "role[storage]"
    - "role[management]"
    

This will start the box with only 2048mb RAM and provision it only with the services required by CoreMedia Studio and the CAE. With

$ cd $CM_BLUEPRINT_HOME
$ vagrant user parameters

you can print out all active configuration settings done with the nugrant plugin.

Build artifacts and fire up the box

Follow the steps below to set up your local isolated development system.

Rebuild intelligently

If you have executed the above commands you are in the initial state to develop code for either Studio or CAE. You can minimize your round trip by using the appropriate Maven commands. Preferably you should make use of the reactor options of Maven to reduce the set of affected modules to be build.

By combining the above parameters, you can minimize the set of required modules to build and therefore reduce the build time dramatically. The most common use case would be to use the parameters -pl in combination together with -rf.

If, for example, you have added some code to the cae-base-lib module and you want to restart the preview-cae-webap with the new code, all you need to do is, stop the tomcat7-maven-plugin and execute:

$ cd $CM_BLUEPRINT_HOME/modules
$ mvn -pl :cae-preview-webapp -rf :cae-base-lib clean install

If the build succeeded, you can simply restart the web application and your additional code will be active.

Reprovisioning Server Components intelligently

The initial provisioning of the box takes a lot of time and should therefore only be done rarely. Instead, you can reprovision your box only with those RPMs that contain your changes. To achieve this, the same Maven optimizations as shown above should be applied.

Note

To prevent you from starting your boxes from scratch each time you start developing, you should get familiar with the additional Vagrant commands to suspend and resume boxes as described in Section 3.5.2, “Working With the Box”; Another interesting approach is to use the sahara plugin for Vagrant, it provides you with a sandbox functionality that allows you to either commit all happened changes or rollback to the last committed state. This is especially usefully, when you are developing features that alter the content repository and you want to rerun the feature on a constant repository state. In that case you can start a sandbox, provision your upgrades, run the test or tools, rollback and your round-trip is closed.