Broken and Dirty Development Components

What are broken development components?

Sometimes the Component Build Service (CBS) reports about broken development components (DCs). This topic explains what exactly a broken DC is in CBS and also gives some hints how to deal with broken DCs.

Having broken DCs does not usually mean that there is something wrong with the SAP NetWeaver Development Infrastructure (NWDI). In many cases, these are just errors in your modifications or in your custom development. There are two reasons why your DC may get broken:

Your DC was activated forcefully even though the build failed during activation.
There is something wrong with another DC that is used by your DC. For example, there may be an incompatible change in a DC you are using (for example, a method was deleted from a Java interface of the used DC).

Broken after forceful activation

When you activate a change (the activity that contains the changed files to be more precise), the CBS analyzes the affected files and determines the DCs to which these files belong. These are the DCs that are directly modified by the change. CBS first tries to build these DCs. If the build fails, the activation request is rejected.

But sometimes you want to activate the change even if the build fails. This makes sense, for example, if you are absolutely sure that the build error is not caused by your change. It could be caused by a problem in a used component. If you activate your change by force , it will be available in the active Design Time Repository (DTR) workspace and, after the used DC is fixed, your DC will be built automatically without any further action from your side. (DTR is the NWDI's WebDAV/DeltaV based source code versioning system. Changes are first made in a virtual location called the inactive workspace . By activating an activity the changes are promoted into the active workspace, from where they can safely be used by others.)

If you activate a change to a DC even if the build failed, the DC is marked by CBS as broken . This indicates that the latest build results on CBS (built before the change) do not match the current content of the active workspace in DTR.

Broken after automatic rebuild

The second reason why a DC can become broken is because of a failing attempt to rebuild the DC after a used DC was changed. The NWDI prevents activation of code that cannot be compiled. But it does not prevent activation of code that breaks some other DCs that depend on your DC. If the modified DCs can be built successfully, the change gets activated. Other DCs that use the modified DCs are rebuilt automatically. This is necessary in two cases:

The using DC assembles results of the modified DCs. If the content of the public part with purpose assembly has changed, the new results must be assembled.
The using DC depends on a public part with purpose compilation , and the content of the public part was changed. The using DC must be rebuilt because input for some generators may have changed and in order to check if there are incompatible changes in interfaces published by the used DC.

If the using DC was rebuilt successfully, the CBS starts the next wave of rebuilding: it may be necessary to rebuild the using DCs of that DC as well. If the content of the public parts was not changed, the process stops here. If the content of the public parts was changed, the rebuild process continues with the next wave. But this can only be decided after the first rebuild is complete.

Example

For public parts of type assembly , the change in a Java DC could lead to the rebuild of a Web Module DC that assembles the JARs from the Java DC. The rebuild of the Web Module DC would trigger the rebuild of an Enterprise Application DC that assembles the Web archive. The same can happen with public parts for compilation . Assume DC1 exposes an XML file in a public part. DC2 declares a dependency to this public part. In the content of DC2, the XML files exposed by DC1 are used as input for generating some Java classes. In DC2, these generated Java classes are exposed in a public part for compilation. The exposed classes are imported in Java classes in another component DC3. If the public part of DC1 is modified, CBS has to rebuild first DC2 and then DC3. This way, one change can trigger an avalanche of rebuilds.

Asynchronous rebuilds and dirty DCs

It is clear that for non-trivial projects the rebuilds can take a lot of time. The design goal was to make the build results of a change available as soon as possible, and to support parallel work in a team.

This could only be achieved by executing the rebuild of used components in an asynchronous way.

CBS activates the modified DCs immediately. It does not wait until all using components are rebuilt. During activation of the modified DC, it only schedules requests for rebuilding the using DCs. DCs that are scheduled for rebuild are called dirty DCs. For dirty DCs, CBS creates internal build requests. These requests are put into the request queue together with those activation requests that are created by the developers. The dirty DCs are rebuilt later when CBS fetches the internal build request from the queue and executes it.

Note that the number of dirty DCs may increase during the rebuild.

This happens, for example, if the second level of using DCs contains more DCs than the first level. In this case, the second wave will show an increased number of dirty DCs. Figures 1a and 1b give an example:

Figure 1: Rebuild of DCs in waves

Recommendation

We recommend that you always create dependencies to specific public parts and not to the whole DC. If you create a dependency to the whole DC, your DC is rebuilt whenever any of the public parts of the used DC was changed. Unnecessary rebuilds are avoided if you create dependencies only to those public parts you really need. It may also be a good idea to create multiple public parts for different functionalities offered by your DC, so the users of your DC can select the public part with the functionality they actually need. You can look for follow-up requests using the Request Details view in the CBS Web UI.

What if the rebuild fails?

The consequence of the asynchronous rebuild is that rebuilds of using DCs may fail long after the modification of the used DC was activated.

Example

Assume that you change your DC my/library and the activation succeeds. A few minutes later, CBS tries to rebuild DC my/bean which uses my/library . But you made an incompatible change to a Java interface in my/library and so the build of my/bean fails. CBS cannot reject the change anymore because it is already active. However, it must somehow signal that there is a problem. The solution: CBS marks DC my/bean as broken. It is broken because it should have been rebuilt but the attempt failed.

One important guideline that helps to avoid broken DCs is to be careful with changes to public parts. It is a good idea to establish some development rules. For example: only compatible changes are allowed in public parts.

Propagation of broken state

If component my/bean was rebuilt successfully, the next step would be to rebuild component my/application which assembles my/bean . But this makes no sense if the rebuild of my/bean failed and my/bean is broken. Instead of rebuilding my/application , the CBS marks my/application also as broken.

Figure 2: Broken used DCs and propagation of brokenness

The example shows that there are two types of broken DCs:

DCs which are broken because the build failed for this DC. In CBS Web UI these DCs are named broken by itself. DC my/bean is an example.
DCs which are broken because a used component is broken. Brokenness was propagated without even trying to build this DC. In CBS Web UI, these DCs are named broken because of used DCs. DC my/application is an example.

More information about how to fix broken DCs: Fixing Broken Development Components .