Rebuild of Dependent Development Components

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

·        Incompatible changes can prevent the used development components from being successfully built. This must be recognized immediately.

·        The build results of the used development component can change.

The using development component 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 development components happens asynchronously and is not part of the activation of the used development component. This allows changes to be activated immediately. If you waited until all dependent development components 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 development component A is activated.

       2.      CBS notes that development component B uses the changed development component A.

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

The queue is processed until it is the turn of development component B.

       4.      CBS tries to build B.

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

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

       5.      In this case, either development component 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.