The first time that you open the product, you specify a workspace,
which is a directory in which to store files that are specific to
your development effort. You then work in the workbench,
which is the development environment that you use to create and work
with the workspace.
As you develop code in the workbench, you create information units
that are in a hierarchy. Projects are directories that
include folders; each folder includes one or more files; and each
file includes definitions of some kind.
Projects
A
project is
a collection of folders and files that represent a defined subset
of a development effort. You might define the subset according to
one or more of the following criteria:
- A business problem to be solved
- The development group that is writing the code
- The type of code; for example, a Rich UI application or a collection
of services
- Your strategy for archiving code and for controlling the version
of a given set of source code
- The maximum size of the code in a given project
- Your testing strategy
EGL projects are for storing source code, and Web projects
are for organizing the output that you intend to deploy to a target
environment. For details on transferring data from the one kind of
project to the other, see "Deployment of Rational® EGL Community Edition applications."
An
EGL project is typically structured as follows:
- The project is composed of folders
- The folders are composed primarily of packages, but also include
some files that are used to transform EGL source code into a deployable
output
- The packages are composed of files
- The files contain the EGL source code. The code is composed of EGL
parts, which are customized definitions that fulfill a development
purpose:
- A part might be a logical unit; for example, the source code for
a service that places employee information into a database.
- A part also might be a data type; for example, a Record part that
defines the kind of information that is stored for any employee. The
Record part named Employee might include an employee
number, a name, and an address.
An EGL project can be independent of other projects or
can reference other projects. For example, you might create three
EGL projects: one for a Rich UI application, one for a service, and
one to store the Record parts that are referenced in the source code
stored in each of the other projects. For details about how one project
references another, see “EGL build path.”
Folders
An EGL project includes one or more
folders. By default, every EGL source project includes the EGLSource folder,
which includes packages. You can create other folders at the same
level as EGLSource.
Packages
An
EGL package corresponds
to a hierarchical set of folders in which the lowest-level folder
holds files that contain EGL parts. Package names follow these conventions:
- In general, a package name is a sequence of identifiers that are
separated by periods (.), as in this example: com.myCompany.myCommonPkg.
Each name corresponds to a subfolder at development time and, for Java™ output, at deployment time.
In this example, the directory structure includes the com folder,
the myCompany subfolder, and the myCommonPkg subfolder.
- As a result of a collaboration or merger, your work might be combined
with the work of another organization. To ensure that your package
names are unique, make the initial part of a package name an inversion
of the Internet domain name of your company. For example, if the domain
name is ibm.rational.software.com, the package names might
start with com.software.rational.ibm.
- The rules for specifying the lowest-level qualifiers in a package
name vary from company to company, as different packages might reflect
a difference between development groups, business purposes, runtime
platforms, or some other characteristic of the business.
- A source file can reside in a default package, which is in a high-level
folder, such as EGLSource. You might not want
to use a default package because other packages cannot access the
parts in such a package.
The preceding conventions emphasize the relationship of
a package and a folder structure. Logically, however, an EGL package
is only the collection of parts. The folders and files represent how
those parts are stored.
All EGL source code is in a package
and can access all parts in the same package, even if the code is
spread across different files in a project. The parts in one package
can reference the parts in a second package.
Do not use the
same package name in different projects; using identical project names
might create unintended consequences at development time.
Files
You can specify the following kinds
of files: