The design build path defines the hierarchy of the projects
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 located in another project
of the location is impossible and a reference search retrieves the
results 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. 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 it contains, from the projects
contained in the other layers. The projects contained in the 0-level
layer (comparable to the tree root) are visible from the projects
contained in all the other layers. However the projects contained
in the highest-level layer are not visible from any other project.
Projects
which 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 which
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 which 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 required
by the selected projected, can be viewed, but not modified,
- By right-clicking a project in the Design Explorer view,
and selecting
- By selecting the project in the Design build path wizard
and by clicking 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.