When Rational Business Developer V9.1.1 was released, a new feature called the "
EGL Deferred Work" feature was introduced. Information on this new feature can be found in the
Knowledge Center or in the EGL blog entry titled "
Using the version 9.1.1 EGL Deferred Work feature". Since then, a new extension point has been added to allow customer or 3rd-party written plugins to participate in the deferred work process by gaining access to the deferred work information.
With this extension point, the RBD user interface logic for any deferred work will now automatically call an extension point for every part placed onto the deferred work queue, allowing the customer or 3rd-party written plugin to accept information about the part that needs to be compiled. This information would ideally be used as input for some type of background automated build system or to store it in a database for impact analysis. This feature is available with the next release after Rational Business Developer V9.1.1 or with Rational Business Developer V9.5.
Let's open the door to what is potentially one of the more powerful features included with the deferred work queue logic, by expanding on this topic. Every time a change is detected that defers the compilation of a generate-able part (like a program, handler, service, form group, data table, UIRecord or library), causing that part to be added to the deferred queue, a call-out will be made to an extension point. Multiple customer or 3rd-party written plugins may exist and each is able to contribute code to this extension point. Each of these contributing extension point classes will be called, allowing any amount of customer-written or 3rd-party logic to be added to the process. This logic could perform any number of activities, such as adding part names to a master list, or transmitting the part name to a build server. In order for a plugin to be called by this extension point processing, the plugin needs the following:
- the manifest.mf file for the plugin must include dependencies on org.eclipse.core.resources, org.eclipse.ui and com.ibm.etools.egl.ui
- the plugin.xml must have this extension point defined, where the action class points at the user-written class in the plugin
<extension
point="com.ibm.etools.egl.ui.eglDeferredCompileActions">
<action
class="demo.deferred.compile.DeferredCompileAction">
</action>
</extension>
- the user-written class, defined by the action class, must have code that extends the EGLDeferredCompile class and contains a method called acceptChange that is to be invoked each time an entry is added to the deferred work queue. This example shows how this method will be called. The comments describe the arguments passed to the acceptChange method.
package demo.deferred.compile;
import org.eclipse.core.resources.IFile;
import org.eclipse.core.resources.IProject;
import com.ibm.etools.egl.ui.deferredCompile.EGLDeferredCompile;
public class DeferredCompileAction extends EGLDeferredCompile {
public DeferredCompileAction() {}
public void acceptChange(IProject sourceProject, String sourceFile, String changedElement, IProject targetProject, IFile targetFile, String affectedTarget) {
// This method will be called for every generate-able part that gets added to the deferred work queue.
// The same target could be added multiple times, so duplicates can happen.
// The sourceProject is an Eclipse project object that contains information about the project of the part that got changed.
// The sourceFile is a string that is the name of the file containing the changed element part
// The changedElement is a string that is the name of the element part (like a top-level function, record or data item) that got changed and is causing the affectedTarget to need compilation.
// The targetProject is an Eclipse project object that contains information about the project of the target part that needs compilation.
// The targetFile is an Eclipse file object that contains information about the file of the target part that needs compilation.
// The affectedTarget is a string that is the name of the generate-able part needing compilation. This name includes the extension and path within the Eclipse workspace.
return;
}
}
For example, let's say a change was made to an EGL record like this:
As you can see from the above "Deferred Work View" that there are 3 generate-able parts that were affected by the change to segtestrec1. For each of these 3 parts, the acceptChange method is called, passing information similar to this:
It is important to understand that the call-out to the user-written class is done from the UI thread. This means that the time taken for the user-written logic to complete will be reflected in the UI response time. This could cause the UI to appear to be unresponsive and frustrating to an end-user. You might want to consider writing the logic in the extension point to be attached asynchronously to a background thread, thus allowing the return to the UI thread to be fast. This will give a better end-user experience.