The design build path

The design build path defines the hierarchy of the projects that are involved in the location. It is used to resolve the links between the instances of the various projects included in the location.

To resolve the links, the design build path explores the projects hierarchy. It applies to all the instances of the location. If it is not defined, the resolution of the links is limited to the current project. Hence, calling an instance that is defined in another project of the location is impossible and a reference search retrieves the results that are found in the current project only.

The project from which you open an instance or generate it is the starting point for the upward exploration of the design build path. This project constitutes the work context of the instance.

If you used the Pacbase migration procedures and imported the instances into the location, the design path is automatically defined according to the hierarchy of the Pacbase Libraries. In the case of a breakdown by entity type, you find all of the projects that are created from the splitting of the Libraries and their hierarchy.

However, if you created your projects and instances from scratch, you must specify the projects hierarchy in the Design build path wizard available from the location.

There are two types of project organizations in the build path:
  • The tree organization, as it exists in Pacbase. With this organization, a project depends on all the projects located higher in the hierarchy. Its build path is then automatically constituted of all these projects.
  • The layer organization. With this organization, the projects are distributed in a stack of layers. The level of each layer reflects the visibility level of the projects that it contains, from the projects that are contained in the other layers. The projects that are contained in the 0-level layer (comparable to the tree root) are visible from the projects that are contained in all the other layers. However, the projects that are contained in the highest-level layer are not visible from any other project.

    Projects that belong to successive layers do not necessarily have a dependence link. A project is required by a project of a higher-level layer only if it is explicitly checked. You can then create a build path that respects the granularity of the dependencies between the projects.

    Example: A 0-level layer contains three projects: A, B, and C. The 1-level layer contains two projects: D and E. With the layer organization, you can specify that project D depends on projects A and B in layer 0 and that project E depends on projects B and C in layer 1. Such a granularity is impossible in a tree organization.
    Important: The following rules apply:
    • A layer contains projects that have no dependence link between one another.
    • Layers are ordered. The projects are displayed in the order of the layers in all the build paths.
    • Projects are ordered inside the layers. They are displayed in the same order in all the build paths.
You can access the design build path in different ways:
  • The whole design build path of the location can be viewed and modified. Right-click the location and select Properties.
  • A partial view of the path, which displays the projects that are required by the selected projected, can be viewed in two ways:
    • Right-click a project in the Design Explorer view and select Properties > Root paths properties > Design build path.
    • Select the project in the Design build path wizard and click Properties.
  • Another partial view of the path, in which the work context constitutes the lowest project of the hierarchy, can be viewed but not modified. From the Overview tab of the instance editor, click Hierarchy.

To be shared, the design build path must be saved onto the Rational Team Concert™ server.


Feedback