This document covers the following topics:
The major advantage of NaturalONE is that it supports out-of-the-box development in a team. Using the local mode, several developers may work on the same application at the same time. They do not interfere each other because each developer has his own workspace. But how do you synchronize the work of each developer? A versioning tool is required for this purpose. The versioning tool allows you to check out a project into the workspace, work on the project, and merge the changes back into the versioning repository. Team support is based on such versioning tools. It is key. Without a versioning tool, it is almost impossible to work with many developers synchronously on one and the same application at the same time.
Examples of versioning tools that are easy to use in Eclipse are CVS, Subversion (SVN) and GIT. Eclipse supports versioning tools via the Team menu and support for CVS is already built in. See also Using a Version Control System in the Introduction.
You must also set up a team repository server which stores the versioned items. For more information, see the documentation of your preferred versioning system.
The versioning tool solves the problem of synchronizing several developers when working on the Natural source. But what about the cataloged objects (also called "generated programs" or "GPs")?
Just to remind you: The application was downloaded from specific libraries in the Natural environment into the workspace (either into a new project or an existing project, depending on the command that was used in the Natural Server view). The same libraries as in the Natural environment are also used in the workspace. When an application in the workspace is built, the sources are cataloged in the Natural environment, in the same libraries as in the workspace. If many developers are working on the same library, it is possible that one developer overwrites (recatalogs) the changes made by another developer. You avoid this problem by switching on "private mode" in the properties of the Natural project. What does this mean?
Let us assume the following:
Two developers are working on the same application which is mapped to a Natural server environment (very similar to the local Natural runtime of NaturalONE). Each developer is changing the application in his own workspace. For testing purposes, each developer builds the project on the server. The Natural builder always checks whether a so-called "private-mode library" for a developer exists on the server (that is, whether there is a separate library for each developer). The naming convention for such a private-mode library can be defined in the Natural preferences. When private mode has been switched on, the source is cataloged in the private-mode library. When a developer invokes the command for a source in the workspace, the builder ensures that the appropriate cataloged object is executed on the Natural server. Thus, both developers may test their changes without interfering each other. In a Natural Security environment, the private-mode library inherits the same credentials as the original library by default. There is no need for a system administrator to define this private-mode library in Natural Security. However, the administrator can set so-called "development mode options" in Natural Security. These options determine how Natural Security controls the use of Natural server actions triggered by Navigator view actions. For detailed information, see Protecting the Natural Development Environment in Eclipse in the Natural Security documentation, which is part of the Natural documentation.
Note:
The private-mode libraries are created automatically when building
projects in private mode. It is not possible to change a private-mode library
in the Natural Server view, and it is not possible to
change any object in a private-mode library (for example, it is not possible to
edit such an object). The corresponding commands in the context menu are
unavailable (gray). For further information, see the description for
Private
Mode in Changing the Project
Properties.
When all tests have been completed, each developer has to merge his changes into the versioning repository. Based on the final repository contents, the application has to be deployed to the Natural server. NaturalONE provides a deployment tool for this purpose. As a result of merging the changes, each developer has the same revision of the application in his own workspace (after an update from the repository). And, via deployment, the related cataloged objects are now available on the Natural server. By default, the objects are deployed to the application libraries, not to the private-mode libraries.
Experience shows that about 60 to 70 percent of changes on an existing application can be merged to some extent automatically, without user interaction. The remaining portion of merging the sources has to be done by the developer manually, but the versioning tools provide functionality which supports manual merging of sources.
Referencing of projects is a good way to separate logical parts of an application. For example, you can define a project which contains just the DDM and data area sources. Assuming that these sources are not changed very often in an existing application, the separation gives the development team a better overview of the different parts of the application. Each developer can just use his own parts in a project and does not need to store these common parts in his own project.
Referencing of projects requires that the steplib chain is set accordingly.
There is always a 1:1 relationship between an Eclipse instance and a workspace. It is not possible to share one workspace among different Eclipse instances. This concept ensures that one developer is not disturbed by the work of any other developer. NaturalONE also follows this concept. If you look at your workspace on disc, you will see a directory named .naturalone. Within this directory, you will find the fuser directory which contains all Natural objects of the local runtime.
In the NaturalONE context, fuser is the root
directory entry for the Natural environment. "FUSER" is a Natural
term which stands for "Natural system file for user programs". On
UNIX, Linux, Windows and OpenVMS platforms, the FUSER is located
on disc. On mainframes, the FUSER is located in a database called
Adabas. This is the reason why it is called a system file.
Having the FUSER located in your own workspace supports the
idea of separating the development environments (that is, the workspaces in the
Eclipse world). If you make use of a Natural server, you should work in private
mode (see above). This also ensures that the development works of different
developers are kept in separate places.
As mentioned earlier, NaturalONE keeps the Natural parameters that are
used in the Natural environment also locally in the workspace. This ensures
that the Eclipse environment and the Natural environment are configured
identically. When the project on which you are working has been checked out
from a versioning repository, you will also get the parameter settings for this
application from the repository (provided that the corresponding files have
been checked in). You can imagine that it would be dangerous to commit your own
parameter changes to the repository (for example, if you change the
DC parameter for some testing reasons) and then make
them available for the entire development group, where no one knows (and does
not expect) that, for example, DC has been changed.
To circumvent this issue, NaturalONE makes use of the temporary store of Eclipse. You may change any Natural parameter settings locally in your workspace. By default, they are not committed to the versioning repository with the changed Natural sources. After you have tested the changed parameter settings and they work fine, you have to make your parameter settings globally available. To do so, invoke the project properties, select Natural in the tree of the resulting dialog box, and then choose the button. The next time you commit source changes to the repository, the changed parameter settings are also stored in the repository.
If you are working with a Natural environment, the locally stored parameters are used to configure the Natural environment (see also Application Parameters in the Project Properties).
