SAP Commerce: Reducing Compile Time

SAP Commerce developers everywhere face the problem speed of building/restarting hybris. Probably everyone knows this is a long time waiting for the project to build and waiting for the server to start. In cases when the developer makes frequent changes in the code and wants to see the result immediately, the work is significantly slowed down. Many developers use JRebel and similar tools, but unfortunately, they are not suitable for everyone and don’t work for a number of cases. This article explains how to make the compile time shorter.

The method described below can significantly speed up the system build in most cases. The essence of it is that the build is performed only for extensions whose files have been changed. An attentive developer may object that Hybris already does this out of the box, but it often happens (for example, in our project) that some heavy operations are performed in the before-build stage, generates some files again and again. And these operations will be performed regardless of whether the source code was changed in the extension. It’s painful when the developer just changed one or two files and doesn’t need to call all the build operations again.

Solution

There is a macrodef task called extensionsbuild which is, as its name says, responsible for the extension build. You can find this definition in bin/platform/resources/ant/compiling.xml

The code below demonstrates the approach how the build rules are implemented in SAP Commerce Cloud:

As you can see, there are two callbacks before_build and after_build which are executed anyway. To fix this, move the callbacks inside the <outofdate> element. Thus, the instructions will only be executed if the extension source codes have been changed. In order not to change the build mechanism globally, create your macrodef in one of your custom extensions. The code should be located in buildcallbacks.xml.

In the example below, macrodef has name quick_extension_build:

To call our customized macrodef, create a new ant target, named “quick” for example. This target will cause quick_extension_build for each of the extensions of the project. The target may look like this for example:

How to use it?

To call the accelerated build enter in the console:

# ant quick

How faster?

The stats below are available only for the v.5.7. The setup has 103 extensions in extensions.xml. The build was tested on Xubuntu 16.04, Intel Core i7-6700 3.40 GHz processor, DDR III RAM 16Gb.

I got with generic ant all. Build time is 30 seconds\

With ant quick with modified source files of a single extension: 5 seconds

As you can see, the change has significantly reduced build time.

* * *

You have to be sure that you use the solution just for cases when you have minor changes in your project, if you know what’s changed on your source code and if those changes are not ubiquitous. 

You should not use this solution if you have changed extensions.xml for example, or you did git pull and have a lot of changes on the project.

I hope that this knowledge will help you in your work.

Published by
Aleksandr Romanov
Software Engineer – EPAM Systems