Glossary | IBM Rational ClearCase, Ant, and CruiseControl: The Java Developers Guide to Accelerating and Automating the Build Process

A number of the definitions in this glossary are taken from one of three sources: Software Configuration Management Strategies [Bellagio05], ClearCase documentation [ClearCase03], or Rational Software's Rational Unified Process [Kruchten03].

Active Development Line: A project's integration branch containing the latest development baseline. The Active Development Line is used in combination with a Private Workspace for day-to-day development and integration.

active object: A derived object that has not or is yet to be staged. Such an object is view-private rather than under version control.

activity: A ClearCase UCM object that tracks the work required to complete a development task. An activity includes a text headline, which describes the task, and a change set, which identifies all versions that you create or modify while working on a version. You must associate that version with an activity. If your project is configured to use the UCM-ClearQuest integration, a corresponding ClearQuest record stores additional information, such as the activity's state and owner [ClearCase03].

administrative VOB: A VOB containing global type objects that are copied to client VOBs on an as-needed basis when users want to create instances of the type of objects in the client VOBs. Administration VOBs are not a special type of VOB. They are defined as relationships that a VOB can have with other VOBs.

agile development: An umbrella term for individual software development methodologies such as Crystal methods, eXtreme Programming, and featuredriven development. Agile development methods emphasize customer satisfaction through continuous delivery of functional software. Although similar to iterative development, agile development methods typically promote less rigorous process enforcement.

artifact: A piece of information that is produced, modified, or used by a process. It defines an area of responsibility and is subject to version control [Kruchten03].

attribute: A metadata annotation attached to an object in the form of a name/value pair. Names of attributes are specified by user-defined attribute types; users can set the values of these attributes. For example, a project administrator might create an attribute type named QAed. A user then could attach the attribute QAed with a value of yes to versions of several file elements.

attribute type: An object that defines an attribute name for use within a VOB. It constrains the attribute values that can be paired with the attribute name (for example, an integer in the range 1 to 100).

base ClearCase: A term that is often used to define the implementation of ClearCase and ClearQuest without UCM, or the set of ClearCase objects that are not part of the UCM usage model, such as branches, attributes, and labels.

baseline (UCM): A ClearCase UCM object that typically represents a stable configuration for one or more components. A baseline identifies activities and one version of every element visible in one or more components. You can create a development stream or rebase an existing development stream from a baseline.

bill of materials: The bill of materials lists the constituent parts of a given version of a product or application and where the physical parts may be found. It describes the changes made in the version and refers to how the product may be installed.

branch: An object that specifies a linear sequence of element versions.

branch/LATEST development: A branching strategy in which team members work in isolated views but check out and check in changes on the same branch. Changes become visible to other team members at check-in time rather than at file-save time. Branch/LATEST development minimizes isolation and maximizes integration.

branching strategy: A strategy for isolation and integration of changes on a software project through the use of branches. A branching strategy defines the types of branches you use, how these branches relate to one another, and how you move changes between branches.

build: An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product [Kruchten03].

build auditing: The process of recording which files and directories (and which versions of them) are read or written by the operating system during the course of a build.

build avoidance: The capability of a build program to fulfill a build request using an existing derived object, rather than creating a new derived object for the specific build step. This capability is usually associated with the clearmake program.

build distribution: The process of distributing the build process across a number of servers or computer processes so as to shorten the total build time.

build management: The identification and definition of what to build, the execution of the build process, and the reporting of its results. Build management capabilities also include build auditing, build avoidance, and build distribution.

Change Control Board (CCB): The role of the CCB is to provide a central control mechanism to ensure that every change request is considered, authorized, and coordinated properly [Kruchten03].

change request: A general term for any request from a stakeholder to change an artifact or process. Documented in the change request is information on the origin and impact of the current problem, the proposed solution, and its cost.

change set (UCM): A list of related versions associated with a UCM activity. ClearCase records the versions that you create while you work on an activity. An activity uses a change set to record the versions of files that are delivered, integrated, and released together.

classpath: An environment variable or build file setting that tells the JVM where to look for Java programs. The entries in a classpath should contain either directories or JAR files.

clearmake: A make-compatible build tool that is part of the ClearCase product and that provides build audit and build avoidance features.

cleartool: A command-line interface to ClearCase operations. You can use it to execute single commands (as in cleartool checkout), or you can use it interactively by starting a cleartool shell.

CMMI: Capability Maturity Model Integration. A method of evaluating the maturity of organizations. The CMMI was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University.

component (UCM): A ClearCase object that groups a set of related directory and file elements within a UCM project. Typically, you develop, integrate, and release the elements that make up a component together. A project contains at least one component, and it can contain multiple components. Projects can share components [ClearCase03].

composite baseline (UCM): A UCM structure that logically associates baselines. A composite baseline can itself be a member of another composite baseline.

configuration record: A bill of materials for a derived object, indicating exactly which files and directories (and which versions of them) were used as inputs to the build, what executables (such as compilers) were used to build them, and which files or directories were created as outputs.

configuration specification: A set of configuration rules specifying which versions of VOB elements a view selects. The configuration specification for a snapshot view also specifies which elements to load into the view.

continuous integration: The process of frequently integrating individual developers' changes into a product's integration environment. Continuous integration normally necessitates a fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate daily, thus reducing integration problems.

continuous staging: The process of accumulating the output of multiple continuous integration builds into a staging area and automatically executing a system build.

deliver (UCM): A ClearCase operation that enables developers to share their work with the rest of the project team by merging work from their own development streams to the project's integration stream.

deployment: The act of moving staged or packaged artifacts to other systems for further testing or release.

deployment component: A built object or executable such as a .jar, .dll, or .exe file that is part of the complete product or application.

deployment unit: A self-contained, installable, documented, traceable release of a software product or application. The deployment unit includes the contents of a product's release build, its bill of materials, and any other supporting artifacts.

derived object: A ClearCase-specific name for the output files produced during a ClearCase audited software build.

dynamic view: A type of view that is always current with the VOB. Dynamic views use the MVFS to create and maintain a directory tree that contains versions of VOB elements.

EAR: A Java Enterprise archive file. An archive (like a JAR file) containing Java class files and supporting artifacts (such as images). EAR files are used to package J2EE applications for deployment. J2EE files contain additional required files above and beyond JAR files that define the environment in which they are to be deployed and executed.

element: An object that encompasses a set of versions, organized into a version tree. Elements can be either files or directories.

entity: A record in a ClearQuest user database. Every entity is based on a specific entity type. Entities based on UCM-enabled entity types can be automatically associated with activities.

entity type: A metadata object that appears in a ClearQuest schema and that describes the structure of a type of record, including its fields, states, actions, and forms.

full baseline (UCM): A baseline created by recording all versions below a component's root directory.

golden master: A final software release that is used to produce distribution media for customers or end users.

incremental baseline (UCM): A baseline created by recording the last full baseline and versions of elements that have changed since the last full baseline was created.

integration: The process of bringing together independently developed changes to form a testable piece of software. Integration can occur at many levels, eventually culminating in a complete software system.

integration build: A build that is carried out by an assigned integrator or central function to assess the effect of integrating a set of changes across a development team. This type of build can be carried out manually by a lead developer or a member of the build team, or alternatively via an automatically scheduled program or service.

J2EE: Java 2 Platform, Enterprise Edition. An environment for developing and deploying enterprise applications. Defined by Sun Microsystems Inc., the J2EE platform consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multitiered, Web-based applications.

JAR: A Java archive file. An archive (like a zip file) containing Java class files and supporting artifacts (such as images). JAR files are used to package Java applications for deployment.

JavaBean: A reusable component that can be used in any Java application development environment. For a Java class to be a JavaBean, it needs to conform to a simple interface specification.

javadoc: A tool from Sun Microsystems that generates API documentation (in HTML format) from Java source code.

JDBC: Java Database Connectivity. A Sun Microsystems standard defining how Java applications access database data.

JDK: Java Development Kit. A software development package from Sun Microsystems that implements the basic set of tools needed to write, test, and debug Java applications and applets.

JMX: Java Management Extensions. An open extension of the Java language that helps you manage and monitor applications, system objects, devices, and service-oriented networks.

JRE: Java Runtime Environment. Consists of the JVM, the Java platform core classes, and supporting files. It is the runtime part of the JDK and does not include a compiler, debugger, or supporting tools.

JVM: Java Virtual Machine. A virtual machine that runs Java byte code generated by Java compilers.

label: An instance of a label-type object that supplies a user-defined name for a version. A label is attached to a version of an element.

label type: A named tag that can be used to identify a consistent set of element versions. For example, you could create a label type called RELEASE_1 and attach instances of the label type to all the versions of the elements that make up the first release of a software system.

makefile: Details the files, dependencies, and rules by which an executable application is built. Makefiles are executed using the make program. However, clearmake can also be used to execute the makefile in a ClearCase environment.

mastership: The ability to modify an object or create instances of a type object.

MultiVersion File System (MVFS): A directory tree that, when activated (mounted as a file system of type MVFS), implements a ClearCase VOB. To standard operating system commands, a VOB appears to contain a directory hierarchy; ClearCase commands can also access the VOB's metadata. MVFS also refers to a file system extension to the operating system.

package definition file: A template file that defines the set of files to be installed by a release package, its dependencies, and actions. For example, does the installation machine require rebooting or need to create Registry keys?

private build: A build that is carried out by a developer in his or her own workspace. This type of build is usually created for the purpose of checking the ongoing status of the developer's changes.

Private Workspace: An isolated environment where developers can control the versions of code that they are working on. In ClearCase the Private Workspace is represented by a branch-and-view combination.

project (UCM): A ClearCase UCM object that contains the configuration information needed to manage a significant development effort, such as a product release. The project is used to set policies that govern how developers access and update the set of files and directories used in the development effort. A project includes an integration stream, which configures views that select the latest versions of the project's shared elements. It also typically includes multiple development streams, which configure views that allow developers to work in isolation from the rest of the project team. A project can be ClearQuest-enabled so that its activities are associated with UCM-enabled entities [ClearCase03].

Project VOB (PVOB): A VOB that stores UCM objects, such as projects, streams, activities, and change sets. Every UCM project must have a PVOB. Multiple projects can share the same PVOB. See versioned object base (VOB).

promotion level (UCM): A property of a UCM baseline that can indicate the quality or degree of completeness of the activities and versions represented by that baseline. You can use promotion levels to define policy for a UCM project. UCM provides an ordered set of default promotion levels and also supports user-defined promotion levels. The act of changing a baseline's promotion level is called promoting or demoting the baseline.

Promotion Line: A branch created for a distinct level of assembly or integration, such as to integrate a system's components or to allow a site to integrate before executing a remote delivery.

PVOB: See project VOB (PVOB).

rebase (UCM): A ClearCase UCM operation that makes your development work area current with the set of versions represented by a more recent baseline in the integration stream.

recommended baseline (UCM): The set of baselines that the project team should use to rebase its development streams. In addition, when the developers join a project, their development work areas are initialized with the recommended baselines. The recommended baselines represent a system configuration, or set of components, that has achieved a specified promotion level. A baseline becomes recommended when the project manager promotes it to a certain level, such as TESTED.

release: A subset of the end product that is the object of evaluation at a major milestone. A release is a stable, executable version of a product, together with any artifacts necessary to use this release, such as release notes or installation instructions. A release can be internal or external. An internal release is used only by the development organization, as part of a milestone, or for a demonstration for users or customers. An external release (or delivery) is delivered to end users. A release is not necessarily a complete product. It can be just one step along the way, with its usefulness emanating only from an engineering perspective [Kruchten03].

release build: A build that is carried out by a central function, usually a member of the build team. This build is created with the express intention of being delivered to a customer, either internal or external. A release build is also usually created in an isolated and controlled environment.

release management: The packaging and authorization of a release build so as to enable its deployment to a test or live environment. Release management can also involve the creation of a deployment unit for deploying a partial or multiple-product release.

release package: The packaging of a release build into a form in which it is readily installable and deployable.

Release-Prep Line: A branch created for the purposes of conducting or stabilizing a release (while also allowing delivery to the Active Development Line to continue).

RSS: A family of XML formats for syndicating information across the Internet. Rather confusingly, the abbreviation can refer to a number of RSS standards or versions: Rich Site Summary (RSS 0.91), RDF Site Summary (RSS 0.9 and 1.0), or Really Simple Syndication (RSS 2.0). RSS technology allows you to subscribe to Web sites that provide RSS feeds; these typically are sites that change or add content regularly. To subscribe, you typically use a feed reader or aggregator.

snapshot view: A view that contains copies of ClearCase elements and other file system objects in a directory tree. You use an update tool or rebase operation to keep the view current with the VOB (as specified by the configuration specification).

Software Configuration Management (SCM): A software-engineering discipline that is made up of the tools and techniques (processes or methodology) a company uses to manage changes to its software assets.

SSH: Secure Shell. A command interface and protocol for securely accessing remote computers.

staged object: A derived object that has been placed under version control. During the staging process, you can define whether the configuration record for the derived object is to be kept.

staging: The process of putting derived object files under version control.

stream: A ClearCase UCM object that determines which version of an element appears in any view configured by that stream. Streams maintain a list of baselines and activities. A project contains one integration stream and typically multiple development streams.

target: An individual, self-contained part of an Ant build process. Targets typically contain a set of tasks to be executed. Targets can also be dependent on other targets, so that executing one also executes all its dependencies.

task: An individual operation carried out as part of an Ant build process. Tasks typically map to single file system commands or build steps, such as creating a directory, executing the Java compiler, or creating a JAR file. Ant comes with a large set of predefined tasks. You also can create your own tasks.

Unified Change Management (UCM): An out-of-the-box process, layered on Base ClearCase and ClearQuest functionality, for organizing software development teams and their work products. Members of a project team use activities and components to organize their work [ClearCase03].

version: An object that implements a particular revision of an element. The versions of an element are organized into a version tree structure.

version control: A subset of software configuration management that deals with tracking version evolution of a file or directory.

version selector: A ClearCase mechanism that references an individual version of an element. For example, the second version on the main branch of the file foo.java could be referenced using the version selector foo.java@/main/2.

version tree: The hierarchical structure in which all versions of an element are (logically) organized. When displaying a version tree, ClearCase also shows merge operations (indicated by arrows).

Versioned Object Base (VOB): A repository that stores versions of file elements, directory elements, derived objects, and metadata associated with these objects.

view: A ClearCase object that provides a work area for one or more users to edit source versions, compile them into object modules, format them into documents, and so on. Users in different views can work on the same files without interfering with each other. For each element in a VOB, a view's configuration specification selects one element from the element's version tree. Each view can also store view-private files that do not appear in other views. The two kinds of views are snapshot and dynamic.

VOB: See versioned object base (VOB).

WAR: Java Web archive file. An archive (such as a JAR file) containing Java class files and supporting artifacts (such as images). WAR files are used to package Web-based Java applications for deployment. WAR files contain additional required files above and beyond JAR files that define the environment in which they are to be deployed and executed.

winkin: The reuse of a derived object during build avoidance. Derived objects can be "winked in" automatically by the build program (such as clearmake) or manually from the command line by the user.

work product component: A source code, configuration, or documentation file that is part of your product and that is changed as part of a change request. Work product components are usually grouped to form some type of deployment component.

workspace: A generic SCM term for a ClearCase view. Sometimes used to refer to the combination of a view and a stream in a UCM context.

zip: A popular data compression format. Files that have been compressed with the zip format are called zip files and usually end with a .zip extension.