EGL project organization

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:
  • EGL source files contain the EGL parts; for example, a Service part. The file extension is .egl.
  • EGL build files contain the EGL build parts, which guide the transformation of source code to a deployable output. The file extension is .eglbld, and these files are stored in a folder that is immediately within the project. In most cases, the folder is EGLSource.
  • EGL deployment descriptors are central to EGL support for SOA. The EGL deployment descriptor stores information primarily about two different issues: the services that are requested by the logic that you are developing, and, if you are developing a service, the characteristics of the service deployment. The file extension is .egldd, and these files are stored in a folder that is immediately within the project. In most cases, the folder is EGLSource.

    Note that the EGL deployment descriptor is different from the Java Platform, Enterprise Edition (JEE) deployment descriptors, which are web.xml (for WAR files) and application.xml (for EAR files).

  • Many files that are used in a deployed Rich UI application are stored in subfolders within the WebContent folder of the source project. Among those files are graphics files (for example, file extension .gif and .jpg) and cascading style sheets (file extension .css).

Feedback