Rebuild of Dependent Development Components 

After a development component (DC) is newly activated, all DCs that use it, must also be rebuild. There are two reasons for this:

●      Incompatible changes can prevent the used DCs from being successfully built. This must be recognized immediately.

●      The build results of the used DC can change.

The using DC is of type J2EE Enterprise Application and the used of type J2EE Web Module. When building the J2EE Enterprise Application, the Web Application Archive (WAR) of the Web Module development component must be wrapped into the Enterprise Application Archive (EAR). In this case, you must repack the EAR every time a new WAR is created.

The rebuild of dependent DCs happens asynchronously and is not part of the activation of the used DC. This allows changes to be activated immediately. If you waited until all dependent DCs have been rebuilt, this would lead to considerable delays.

Due to the multi-level development landscapes (DEV, CONS, QA, PROD), inconsistencies do not occur in production environments.

The process flow is as follows:

...

...

       1.         A change to a DC A is activated.

       2.      CBS notes that DC B uses the changed DC A.

       3.      CBS generates an internal build request for B. CBS places the internal build request into the request queue. DC B is flagged as DIRTY(rebuild is required).

The queue is processed until it is the turn of DC B.

       4.      CBS tries to build B.

○       If successful, the new build results of B are written to the archive pool and the DIRTY flag is removed.

○       If the build of B fails, an inconsistent state occurs: DC B should have been rebuilt, but the rebuild failed. To indicate this, development component B is flagged as BROKEN.

       5.      In this case, either DC B must be adapted or the changes to A must be undone. In both cases, B is rebuilt and, if successful, the BROKEN flag is removed.