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 .
- 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.