You can use Rational® ClearCase® as a software configuration management (SCM) system for projects created in IBM® Integration Designer.
Installing or updating CCRC for Eclipse and RSA. This topic addresses some specific issues that arise when you use ClearCase. For general information
about using software configuration management systems with Integration Designer, see Using software configuration management systems. For ClearCase documentation, see the
ClearCase information center. For more detailed instructions and best
practices for using Integration Designer with ClearCase, see a presentation
from Joef Huang,
Use of ClearCase in WebSphere Integration Developer. The product name has
changed, but the instructions and advice are still relevant.
There are two ways to use ClearCase with Integration Designer. Inside Integration Designer, use the ClearCase remote client for Eclipse plugin and the ClearCase SCM adapter plugin. Outside Integration Designer, use ClearCase Explorer and ClearCase Remote Client Standalone. The latter method is preferable in most circumstances. If you have a ClearCase or ClearCase LT server installed on the same machine as Integration Designer, the ClearCase server can also act as a client.
Integration Designer provides capabilities that can be activated for developers working in teams. The core team capabilities and CVS capability are enabled by default. The most common Integration Designer support for ClearCase usage is provided through the ClearCase SCM adapter plug-in that is included with Integration Designer. If you install the Rational ClearCase Adapter, an additional capability appears in the list. To use the adapter, you need to enable this capability by selecting .
You can use Rational ClearCase to manage a team's software development process using either of two models. The unified change management (UCM) model supports patterns defined in the Rational Unified Process (RUP). Custom behavior can be specified through the use of policies. Base ClearCase uses triggers, scripts, and utilities to manage the software development process. See "Good development practices" below for tips about using the UCM model effectively.
A VOB (versioned object base) in ClearCase is the permanent data repository in which you store files, directories, and metadata. On a typical Integration Designer project, a single VOB is used to store multiple ClearCase components. Each component stores a logical group of modules and libraries. For large projects, multiple VOBs could be used.
Hint: Using snapshot views usually provides better performance than using dynamic views.
The Business Integration view provides a logical view of the resources in each module, mediation module, and library. Within each project, the resources are categorized by type. Logical resources shown in the navigation tree in the Business Integration view do not necessarily have a one-to-one mapping to physical files. When you use the Team menu options you will notice that the physical files presented in the Synchronize and Repositories views do not directly map to the resources that you see in the Business Integration view. Always work from the Business Integration view when sharing a project or committing changes, so that you share or commit all the necessary resources.
For information about the files that should be managed or excluded from source control, see "Integration Designer artifacts managed in source control" in the related links.
The ClearCase client has a particular way of dealing with files that have the same path and base name, but slightly different extensions. When this situation is encountered, only the file with the longer file name can be added to version control. This behavior may result in BPEL or BSM source files not being added to ClearCase when you are attempting to add a module to source control.
To counteract this behavior, open the ClearCase plug-in menu and search for resources to add to source control. ClearCase will, at that point, have a list of items that can be added.
When you check files into ClearCase, configure ClearCase to allow it to check in identical files.
The identical file check-in helps you to track the relationship between logical artifacts (such as BPEL processes) and the logical artifact's associated physical files. This configuration prevents the occurrence of error windows if you attempt to check in identical files.
Checking in identical files, especially text files, does not increase storage size in ClearCase.
On Windows, you can globally enable the Checkin even if identical preference from any IBM Integration Designer perspective. Select to enable that preference.
On Linux, the option is provided on the check-in window itself each time files are checked in.
If you are using the ClearCase SCM Adapter plugin, do not set the checkout preferences to “Do Nothing.” You can check this preference under .
If you are using the ClearCase SCM Adapter plugin, enable the hijack preference to work disconnected from ClearCase. Select . You can convert hijacks to checkouts after reconnecting.
If you are using ClearCase Remote Client (CCRC), select .
If you are using ClearCase Remote Client (CCRC), you can keep the default checkout set to "reserved" for a more pessimistic strategy. To do that, select .
Some CCRC versions have a menu item. For other versions, select to work disconnected from ClearCase.
When you are sharing work on a project in a ClearCase repository, you need to be careful to keep your own local assembly artifacts (components, imports, exports, or stand-alone references) current. When one user adds a new artifact and checks it in, this change is not automatically communicated to other users. The same is true when a user deletes an artifact from the assembly diagram.
Update your snapshot or ClearCase (web) view frequently when working on assembly artifacts. To properly update all assembly artifacts from the ClearCase repository, right-click the name of the module in the Business Integration view and select . This action will ensure that all assembly artifacts are updated, including new or deleted ones. (Do not update from the Assembly diagram node in the Business Integration view.)
Work in a single stream when you can to avoid merge issues. If you need to work in multiple streams, merge often. Module-level merging is not supported, so avoid concurrent development on the same module. When you need to update files across modules, such as refactoring or compare/merge actions, avoid concurrent development on all the affected modules.
If you are using the Base ClearCase model, the triggers and scripts that you use dictate which actions you can take and what prerequisites must be in place at different points in the development cycle.
If you use Base ClearCase, you do not have to be concerned with silent checkouts being included in the current UCM activities. The disadvantage is that developers are working at the file level instead of the activity level. UCM lets developers work at the activity level instead of the file level.
Based on the model you are using, there are minor differences in the mechanics of user interaction. For example, in the UCM model, you must specify an activity when you version elements. When you use Integration Designer to check in elements, you are prompted to specify a corresponding activity for the new version. Make sure you have at least one activity before you start a build. And before you deliver to the integration stream, rebase the development stream with the most recent baseline.
If you are working in ClearCase UCM mode, work with one activity at a time, and check in all changes for one activity before moving on to the next activity. Always set ClearCase UCM view's default activity to the current activity that you are using. The automated source control operations that occur during refactoring and checkout use that current activity. If you are using serial development with multiple activities, you can create dependencies among activities. In that case, an activity cannot be delivered without its dependent activity.