Rational Developer for System z


Mapping Eclipse projects to SCLM

IBM® SCLM Developer Toolkit provides the capacity to manage, build and deploy Eclipse projects in SCLM. To utilize this feature, you must first map the Eclipse project to SCLM. To map an Eclipse project to SCLM, select the project, right click and select Team->Share Project.

Using the Share Project function, you can take a Java project from the Eclipse workbench, and map it to the SCLM team services provider. Each Java source file, along with related files like .properties and .xml files, can then be managed by SCLM and stored as members on the server.
Note: An option is provided on the main ISPF based SCLM panel that you can use to create an SCLM project to control traditional COBOL and PL/I source. You can use this as a starting point to develop your own SCLM project.

This form of multiple project structure does not map to SCLM directly. Linking one SCLM project to another SCLM project to provide some form of aggregated project structure is a disadvantage because SCLM does not really map cross project dependencies. However, by keeping all related source in a single SCLM project means SCLM will maintain dependencies, so you will know the effect on one part if another related part changes. SCLM provides a way for you to support this multiple project structure within a single SCLM project.

SCLM projects can be defined with multiple source types. Each type can hold a single project. If we tried to store multiple Eclipse projects in SCLM without some form of segregation then each of the project's .classpath and .project files would be overwritten as each project was added to SCLM. The use of different source types enables these files, and all others associated with that project, to be stored safely within SCLM.

For example:

Artwork for image001

This mapping would result in the projects being stored independently within SCLM using the type as the principal differentiator:

For example, EJB1 is stored in the SCLM project SCLMPRJ1 under type EJB1.

Using this structure you can "map" the project structure to independent types within the SCLM project.

Note:
  1. It is not necessary to map a project name in the IDE to the SCLM type name. These names exist independent of each other.
  2. Type names are restricted to eight characters, so a project called "New project with no bugs" could not have the corresponding type name of "New project with no bugs". Some imagination is required: "BUGFREE"!

It is therefore important that the SCLM project structure be planned to accommodate the mapping of different IDE based projects into the single SCLM project structure. This is because, within large SCLM projects, it may be a non-trivial matter to add additional project types, as this requires a change to the SCLM project definition, a rebuild of the SCLM project definition and the allocation of datasets for the new types.

This form of structure is not restricted to J2EE style projects, but could also apply to any situation where multiple projects are being developed that provide some form of dependency upon each other.

The use of multiple SCLM types to store individual projects also relates to the operation of the ARCHDEF structure for the building of these projects.

Artwork for image002

The ARCHDEF file contains the list of files that make up a build. In the J2EE context a build can result in an EAR file being composed of a number of WAR and JAR files. This isolation of projects is similar to the type structure that defines the project in SCLM. By having a high level ARCHDEF that references those parts that make up the build you can have a structured build environment. This relates to the effective definition of project structure when defining the types in SCLM.

By defining the project in a structured manner this also enables:

Recommendations


Terms of use | Feedback



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