Rational Programming Patterns for System z

The design build path

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 Properties > Root paths properties > Design build path
    • 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.


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)