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:
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: - It is not necessary to map a project name in the IDE to the SCLM
type name. These names exist independent of each other.
- 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.
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:
- Migration of files from an SCLM project type or ARCHDEF to a project
without the need to know individual parts.
- The ARCHDEF structure based on type definition also enables project
dependencies to be mapped more effectively. It is common for projects
to reference other projects in the workspace. Use of the SCLM INCL
keyword in ARCHDEFs supports this notion as other projects, referenced
by other ARCHDEFS, can be included by nesting the ARCHDEFs within
higher level ARCHDEFS.
- When building applications with references or dependencies on
other build objects such as JARs, other projects or other classes
there are multiple approaches:
- Should the project refer to a JAR but it is not expected to be
part of the final build package then the library file can be copied
to the system CLASSPATH using the Upload JARS service in Developer
Toolkit. This will have the effect of making that service available
from a different SCLM project. At build time the project references
to the JAR will be resolved. However at runtime, the JAR must be available
in a PATH statement.
- Reference a JAR that is in the same SCLM project through the use
of the CLASSPATH_JARS_FILES property in the build script.
- Include the reference to the JAR via the INCLD statement in the
ARCHDEF. This will build the application with the library reference
into the final build package.
- Include the project as a nested INCL SCLM project ARCHDEF
- Include the dependent JAR in the CLASSPATH directory
Recommendations
- Identify the J2EE project composition in terms of EJBs, Web applications,
etc. so that this structure is defined and can be used to plan the
SCLM project structure
- For each of the J2EE project components, create a corresponding
type in the SCLM project. It is useful to provide some form of meaningful
naming convention to support this.
- As project requirements can change, it is worthwhile to create
additional type definitions to enable the smooth additional of other
components (such as additional EJBs). Additional services can be anticipated
through the type structure.
- You can name the projects independently of the SCLM type, but
some correlation will make administration easier.
- Mapping multiple projects into a single SCLM project is supported
by the type construct. It is also useful to apply some packaging structure
that takes into account the type definition for that project.
- Java style packaging conventions
should also be defined at the project level, so as to avoid the likelihood
of source naming collisions.
- If the IDE development environment is structured with multiple
projects, it is advisable to replicate this structure in SCLM using
type.