![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Setting Up the Development Environment for Multiple Users This chapter discusses the issues and steps involved in setting up a development area in an average networked development environment. Projects allow accessing files, directories, and resources by clicking special icons instead of typing pathnames. Steps in setting a project and a group environment are also presented.
About This Chapter
The major topics covered in this chapter are:
- UNIX System Considerations
- Name Resolution
- Distributing Storage for Subsystems and Views (Apex/Summit)
- Customizing Startup Files
- Creating and Using Apex Projects
- Sessions
- Establishing a Group Wide Environment
UNIX System ConsiderationsFirst, you must consider that you will be developing a large complex system using the UNIX operating system and Apex as a development vehicle. There are a number of important considerations in using networked UNIX workstations.
This section assumes some basic knowledge on UNIX system administration. It is mainly for those who need to know how to setup a development area for major projects.
To illustrate the concepts in this chapter, assume you will be creating a number of subsystems and for Apex/Summit, Apex/Summit views, populating them with many files, performing compiles, links, and executing tests. You will store:
- Source files —— A copy in each library context
- Object files —— A file in each library context in which compilation is done
- Other files —— Copies of text files in each library context where they are placed
- Test data —— Wherever relevant
- Summit/CM database —— In each subsystem storing all versions of all objects in that subsystem (Apex/Summit)
- ClearCase VOB(s) (Apex/ClearCase)
- Other information as appropriate for the project —— reports, specs, documents, and so on
You are going to need a lot of disk space. Not everything will fit in one UNIX file system.
If the development environment consists of a number of distributed workstations and file servers, each may have some number of disks. The UNIX automounter can make all disks available to all developers if it is properly configured (which is highly recommended). Some central servers may be used with lots of disks in order to store everything and/or storage may be more distributed among developer's workstations.
In any case, there are two factors that need to be considered for Apex NFS/Automounter common naming and distributing the storage space for subsystems and Apex/Summit views.
NFS Common Naming
Consider a workstation with a local disk. A file system on the disk is locally mounted in directory /files/c. You can create subsystems on this disk under names like:
/files/c/video_library.ss /files/c/passenger_seat_console.ss
How do other developers using different workstations access these files? This file system must be mounted or automounted on each workstation that is to access it. Apex/Summit requires that all subsystems and views be accessible using a unique canonical permanent name. You can access a subsystem or view using a different name, but the subsystem or view must always be accessible under the permanent name, which is stored in internal Apex databases. Apex/ClearCase requires controlled Rational subsystems to be in VOBs. Rational subsystems created outside of a VOB must following the NFS Common Naming.
Thus to set up a product such as this, some care should be employed. First a generic directory structure that can be used from all workstations should be established. For example, assume that each workstation will have an /apex directory and you will place all subsystems for this project in:
/apex/projects/avionics/
You can set up mount tables or automount tables so that subsystems in this directory can be accessed from all workstations under this name. UNIX, NFS, and the Automounter allow the physical disk storage to be placed arbitrarily on the network.
Apex/Summit
You must tell Apex the permanent name for a directory by explicitly assigning it. The permanent name is the physical location of the directory. Otherwise, files could be accessed using a name beginning with /apex/projects/avionics/..... or, in some cases, /files/c/.... Apex would not know what the permanent name for a referenced subsystem was.
The permanent name is set using the Control > Maintenance > Permanent Name menu item. In this example, you must create the directories initially using the name /files/c/... because it must be created before the alternate mount points can be established. Let's create the directory as:
/files/c/projects/avionics
Then you can select the directory /files/c/projects/avionics in a directory-viewer window and run Control > Maintenance > Permanent Name. Since there is no permanent name established yet, the Enclosing Directory With Permanent Name field will be blank. You need to have system administrators set up an automount entry that mounts:
/apex/projects/avionics
on /files/c/projects/avionics from the workstation that has this disk. Once the automount entries are established, execute the Permanent Name command and fill in the fields with values as illustrated in Figure 26.
Figure 26 Permanent Name Dialog Box
![]()
Apex will now know the permanent name for this subsystem and all users will be able to access it and use it consistently.
Apex/ClearCase
Apex/ClearCase does not require permanent names. To share a Rational subsystem, it simply needs to be controlled inside a VOB directory and the VOB directory mounted using advertised mount points. ClearCase manages a registry which maps the BOV tab to an actual storage location.
Name ResolutionApex name resolution can be used to extend the naming capabilities of the various UNIX shells or can be used in a manner that strictly conforms to a particular shell.
Naming Styles
Apex supports a number of styles for resolving the names of objects in the UNIX file system. Some styles provide strict conformance with the naming rules of particular UNIX shells while other naming styles provide capabilities beyond those available in the standard shells.
The naming style is specified in the APEX_NAMING_STYLE session switch. The possible values are:
- apex
The standard Apex naming style. This style is the default.
- apex_extended
An extended Apex naming style.
- sh
A naming style which conforms to the rules of the Bourne shell.
- ksh
A naming style which conforms to the rules of the Korn shell.
- csh
A naming style which conforms to the rules of the C shell.
- tcsh
A naming style which conforms to the rules of the "tcsh" shell.
- win32
A naming style which conforms the rules of Microsoft Windows 32 naming.
Specific characteristics of the different naming styles are described in the following sections. In all of the naming styles, a leading slash ("/") identifies the root of the file system. The slash character also serves as the name segment delimiter.
Apex Naming
The standard naming style is used when APEX_NAMING_STYLE is set to apex. This style provides a number of useful capabilities beyond those available in standard UNIX shells including expanded wildcards, set notation, indirection, and access to object attributes.
Wildcards
Apex naming supports the following set of wildcard matching rules. Except where noted, these rules are common to the filename expansion rules used by the C shell, Bourne shell, and Korn shell.
- `*' matches any string, including the null string.
- `?' matches any single character.
- `[...]' defines a character list that includes all the characters within the brackets. A pair of characters separated by `-' matches any character lexically between the pair, inclusive. A character list is matched against exactly one character. If the first character following the opening `[` is `!', any character not enclosed is matched. The special characters `*' and `?' lose their special meaning within `[...]'. (Allowing `!' for exclusion is not a property of the standard C shell.(Note that HPUX has standardized the filename pattern matching among all shells; its C shell allows `!' for exclusion))
- `~' is an abbreviation for home directories, when found at the beginning of a name expression; if found anywhere else, `~' stands for itself (not Bourne shell).
A `~' by itself identifies the user's home directory. A `~' with characters between it and a following slash (or end of expression) identifies the home directory of the named user; for example. ~fred is the home directory of user `fred'. The `~' is replaced with the value of the $HOME environment variable. The previously described wildcard characters lose their special meaning when found after a leading `~'.
Any of these special characters can be made to stand for itself by preceding it with a backslash.
The character `.' at the start of a filename or immediately following a `/', as well as the character `/' itself, must be matched explicitly.
Sets
Naming supports set expansion identical to that provided by the C shell. This mechanism textually expands a set prior to resolution of any part of the naming expression; the result of this expansion can be more than one name expression, which can still contain wildcards.
The set delimiters are curly braces `{' and `}', and a comma is used to separate individual components. A set does not define a segment boundary, so they can be used within a simple name. For example, the expression "a{b,c,d}e" expands into the three expressions "abe", "ace", and "ade". Set components are not limited to simple names; for example, the expression "a{b/c,d}e" expands into the two expressions "ab/ce" and "ade".
Indirect Files
Naming supports the ability to resolve name expressions contained in files. Each line of the file is treated as a name expression that is a single set component. The result is the same as if the file content was surrounded with set delimiters and had commas added between lines.
The indirection character is an underscore `_'. It is recognized as indirection only when it appears at the beginning of a name expression, after any sets have been expanded. It has no special meaning when used anywhere else in an expression (even when it immediately follows a `/'). As with the other special characters, a leading underscore can be made to stand for itself by preceding it with a backslash. A `~' that immediately follows an indirection character retains its special meaning as described earlier
An indirect file may itself contain the names of other indirect files in which case each indirect file is expanded in turn.
When a configuration is used as an indirect file, configuration semantics apply. In particular, the expansion of the configuration will result in at most one view per subsystem.
Attribute Evaluation
Naming supports evaluation of all keyword replacement attributes. Attributes may be designated by the "`" character.
Apex/Summit Example
The model associated with a view is returned in the following way:
/src/sub.ss/view.wrk'model
and thus the following command may be run to return the perperties of a view model:
% apex properties "/src/sub.ss/view.wrk'model"
Apex/ClearCase Example
For example, the model associated with a Rational subsystem is returned in the following way:
/vobs/my_vob/my_rss.rss'model
and thus the following command may be run to return the properties of a subsystem:
%apex properties "/vobs/my_vob/my_rss.rss'model"
Extended Apex/Summit Naming
The naming style apex_extended provides all of the capabilities of the apex style shown above and in addition allows the "%" character to be used for attribute evaluation. For example, in this style the command above could also be written as:
% apex properties /src/sub.ss/view.wrk@model
Other Naming Styles
The other naming styles provide conformance with standard UNIX shells.
sh and ksh
The naming styles sh and ksh provide conformance with the Bourne and Korn shells. These styles differ in the following ways from the apex style:
- No set notation with `{` and `}'.
- No indirection with `_'.
- No attribute evaluation with ``' or `%'.
csh
The naming style csh provides conformance with the C shell. This style differs in the following ways from the apex style:
- No character set negation with "!".
- No indirection with "_".
- No attribute evaluation with "`" or "%".
tcsh
The naming style tcsh provides conformance with the "tcsh" shell. This style differs in the following ways from the apex style:
- The character "^" is used for character set negation.
- No indirection with "_".
- No attribute evaluation with "`" or "%".
win32
The naming style win32 provides conformance with the rules of Microsoft Windows 32 naming. In this style only the wildcard characters "*" and "?" are supported.
Distributing Storage for Subsystems and Views (Apex/Summit)In large projects, it will not be possible to store everything in a single UNIX file system. Apex provides the means to place the storage for subsystems and views in different file systems from the directory that contains the subsystems and views. Thus, you can create subsystems and views in a logical place for them and then place the storage in arbitrary alternate locations.
Suppose that you will be creating subsystems
/apex/projects/avionics/video_library.ss /apex/projects/avionics/passenger_seat_console.ss
and so on. You can place the storage for these subsystems in different locations by filling in the storage location in the File > New > New Subsystem dialog box.
Specifically, you want to place one subsystem each on disks whose file systems are mounted on /files/c, /files/d, /files/e and so on. Each of these file systems needs to be network accessible under a permanent name and have that name assigned using the Control > Maintnenance > Permenent Name command.
After subsystems and views are created it is possible to move the storage for them if disks become full or new disks become available.
Customizing Startup FilesCommand-line access to Apex is simplified by adding commands to your home directory startup files. For example:
- 1 . For the C shell (csh), open your .login file and append apex_release/bin to your PATH variable. If necessary, add this line:
- 2 . For the Bourne shell (sh) or Korn shell (ksh), edit your .profile file and append apex_release/bin to your PATH variable. If necessary add this line:
DISPLAY=local_host:
0; export DISPLAY
where local_host is the unique network name of your local workstation.
- 3 . If necessary, edit your .xinitrc file by adding the line:
- 4 . Log out and then log back in so your changes will take effect.
- 5 . To start Apex, start the X server and window manager and enter:
% apexinit
For additional information on the apexinit command, open an Apex shell (Tools > Shell) and enter:
man apexinit
Creating and Using Apex ProjectsWhen there are a number of developers working on a project, there are a number of things that can be set up in Apex to make them more productive and make some of their tasks easier.
When there are a number of subsystems, Apex/Summit views (Apex/Summit), and system configurations, just entering their names can be tedious and time consuming. If there are conventions concerning models, or histories, these may be difficult to remember because they are not used all that often. When you have set up a project, you can access files, directories, and resources named in your project by clicking special icons instead of typing pathnames.
Apex provides the ability to create an object called a project that contains this kind of information and makes it available at various points in the Apex user interface. Projects can be on a per-user basis or shared among groups.
Once created, projects must be activated to be used in an Apex session.
Creating a Project
- 1 . In a directory-viewer window, choose File > New > New Project
.This brings up a New Project dialog box. Alternatively, on the Apex panel, you can click Setup and New.
- 2 . Enter the simple name of the project into the Name field and click OK.
This creates the project file with a template and brings up an editor window.
- 3 . Chose File > Edit to edit the project.
- 4 . Between the lines field Subsystems and end_field, enter the names of subsystems that are often referenced, one per line.
Enter either the full pathname of the subsystem or a short synonym for the subsystem followed by a blank followed by a full pathname.
- 5 . For Apex/Summit, between the lines field Towers and end_field, enter the names of commonly referenced system configurations or views. (Place each on its own line.)
These are the simple view names, such as rev.1.wrk.
- 6 . Between the lines field Places and end_field, place the names of specific objects that will often be referenced.
Enter the full pathname of each object, optionally preceded by a short abbreviation for the place and a blank. Enter one place per line.
- 7 . Similarly for Printers, Models, and Histories (Apex/Summit), enter the simple names of any printers commonly used, full pathnames of models commonly used, and history names commonly used, respectively, if any.
- 8 . Choose File > Save and File > Close.
A project file is simply a text file whose name ends with the extension.apexprj. Project files for a user are stored in the .Rational subdirectory of the user's home directory.
An example of a simple project file named avionics.apexprj for an example project is illustrated in Figure 27.
Figure 27 Editor Window with Project File (Apex/Summit)
![]()
Fields in a Project File
The contents of the various fields in the project are used as aids in entering information in various parts of the user interface.
In text entry fields that have a Navigator Icon, clicking the right mouse button on the icon will pop up a menu that allows you to retrieve names from the Subsystems, System Configurations, and Places fields as illustrated in Figure 28.
Figure 28 Navigator Icon with Text Entry Field
![]()
If an item from the Places cascade is selected, it replaces the contents of the text field. If an item from Subsystems or System Configurations is selected, it replaces any current subsystem or system configuration, respectively, in the text field. For Apex/Summit, this makes it easy to switch to a corresponding object in another system configuration or different view of the same system configuration. Used here, only the first 32 entries in the Subsystems, System Configurations, and Places fields appear.
In the File Selection dialog box, there are icons for Subsystems, System Configurations, and Places that have up to 132 entries from the project fields.
Similarly, Apex uses the contents of the Printers field of a project as the values for the Alternatives Icon pop-up menu in the Print dialog box.
The Models and Histories field (Apex/Summit) contents are used for values for the Alternatives Icon pop-up menu that appear in various dialog boxes.
Format of a Project-File Entry
Each one-line entry in a project file can contain either one or two columns. If an entry contains no white space, it is a single-column entry. If an entry contains white space, the first column of the entry is the part that precedes the white space, and the second column of the entry is the part that follows the white space.
If a project-file entry contains a single column, Apex displays the entire entry in the dialog box field associated with the entry. If a project-file entry contains two columns, Apex displays the text in the first column as an alias for the information entered in the second column.
When you feel that a project-file entry is too long to be displayed conveniently in its corresponding menu field, you can create an alias that will be displayed in dialog box fields in place of the entire entry.
In the preceding illustrations, every entry is a single-column entry.
Activating Projects
To make the contents of a project available to an Apex session, the project must be active. To activate a project:
- 1 . Click Setup on the Apex Panel or choose File > Setup from a directory-viewer window. A Project Setup dialog box is displayed and is illustrated in Figure 29.
Figure 29 Setup Dialog Box
![]()
- 2 . From the Available Projects list, select the projects you wish to activate.
- 3 . Click Add -> to add them to the Active Projects list.
- 4 . Click OK or Apply to make the list of active projects effective for this Apex session.
The list of active projects is saved across Apex sessions, so it is necessary to activate a project only once for a given user.
Projects created after an Apex session has started do not show up in the available projects list by default. To refresh the list, click Apply in the dialog box.
SessionsAn Apex session is the set of windows currently on your screen, along with their positions, sizes, and some aspects of their contents. You can save your session and, optionally, have it restored when Apex is next started. You can also open a session object in the middle of an Apex session; this has the effect of adding windows to your session.
Users can save their sessions when they exit from Apex and have them restored when Apex is next started. This is sometimes desired, but restoring sessions containing many windows can be time consuming so it is not universally the case that restoring your session as it was when it last ended is desirable.
It is often more desirable to create an initial session for a project that contains a few common windows, perhaps a library context window showing library contexts in the development system configuration and perhaps a directory window on the library context that is under development.
Establishing a Group Wide EnvironmentThere are a number of parameters that can be set to customize Apex for more optimal use on a particular project. Here is a partial list of them:
- Project: Provides defaults for navigation, models, printers, and so on.
- Session: Provides default initial configuration of windows and their contents.
- APEX_DEFAULT_MODEL: Environment variable default for model used in creating Summit/CM views or Rational subsystems.
- APEX_DIALOG_PATH: Search path for any dialog customizations. This variable is setup and used in a manner similar to APEX_MENUS_PATH (as described in "How Apex Looks for Menu Files" in Using and Customizing the Apex GUI).
- APEX_MENUS_PATH: Search path for any menu customization, projects, and sessions.
To establish a common environment for a group working on a project:
- 1 . Create a directory to store the custom information.
/projects/avionics/
- 2 . Create a shell script file named config.sh in that directory.
- 3 . In that shell script, set any Apex session environment variables desired (such as APEX_DEFAULT_MODEL).
- 4 . Place any dialog customizations in /projects/avionics/dialogs. These files are named *.dlg or *.ext.
This directory is appended (by apexinit) to variable $APEX_DIALOG_PATH, which is what Apex uses to search for dialog files.
- 5 . Place any Apex script files in /projects/avionics/scripts. This directory is appended (by apexinit) to variable $APEX_SCRIPT_PATH.
- 6 . Place any menu customizations in:
/projects/avionics/editor_files/
This directory is appended (by apexinit) to variable $APEX_MENUS_PATH, which is what Apex uses to search for menu, project, and session files. Menu customization files are named SERVER_TYPE, where SERVER is either "directory", "ada", "text" or "output" and TYPE is either "rules" or "menus" (e.g., directory_menus). These files may also appear in and may be copied from $HOME/.Rational.
- 7 . Place any sessions and projects in
/projects/avionics/editor_files/
This directory is appended (by apexinit) to variable $APEX_MENUS_PATH, which is what Apex uses to search for menu, project, and session files. Project files are named *.apexprj. Sessions are directories that are named *.session.
- 8 . To create the session:
- a .
Configure your session to have the windows and contents desired for others to use.- b .
Save the session using Tools > Session > Save Session. Suppose the session was called avionics_setup.- c .
Then move the directory:
~/.Rational/avionics_setup.session
/projects/avionics/editor_files/
with the UNIX mv command or the File > Move Object menu item.
- 9 . Create the file rational_dir/config/local_dir with the editor of your choice —— Apex text editor, Apex Emacs editor, vi or any other editor. The contents of this file is the one line:
/projects/avionics
If you want this to be used for all versions of Apex you have installed. If you want this setting to apply onto to a specific version of Apex, create the file $APEX_HOME/local_dir in your APEX_HOME for the desired version, this causes rational_dir/config/local_dir to be ignored by that Apex version.
Once this is established, the group environment is established during the Apex start-up by the startup script apexinit, which automatically sets APEX_MENUS_PATH, APEX_DIALOG_PATH, APEX_SCRIPT_PATH to include the subdirectories of /projects/avionics and executes the group's /projects/avionics/config.sh script if it is present.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |