Introduction to EGLAR files and binary projects

An EGLAR file is a zip file that contains the compiled, intermediate representation (IR) version of one or more EGL parts.

You can generate and deploy output from parts that are stored in the EGLAR file. In addition, you can use those parts to resolve references from EGL source code that is external to the EGLAR file. For example, the EGLAR file might include an Interface part, and you can use the definition to create a variable based on that part. Also, widget types that are defined in the EGLAR file can be displayed in the palette used by the EGL Rich UI editor.

The general benefits of EGLAR files are as follows:
You create an EGLAR file by exporting a project in either of two ways:
The following table identifies some of the differences between the two:
Table 1.
Feature Binary project Stand-alone EGLAR file
Source code is available (read-only) Yes No, except for stand-alone functions
The EGL debugger can step into the code Yes No
The EGL software development kit (EGLSDK) can access the code No Yes

The next sections give details on the two variations.

Stand-alone EGLAR files

The stand-alone EGLAR file includes IR files as well as other resources such as graphics files and generated output. The EGLAR file cannot include source code, with the following, small exception: stand-alone function parts can be present. The lack of source code means that the debugger skips over the code as if the IR files were a generated output.

Note: People who receive the EGLAR file will be able to view the stand-alone function parts, which are most often found in code migrated from VisualAge® Generator.
To access a stand-alone EGLAR file, set a project's EGL build path to access the file. Alternatively, import the stand-alone EGLAR file into a non-binary project, which is hereafter called Project B. In that second case, an EGLAR file is treated in some ways as if the file were a project:
  • The EGLAR file is available to other code in the same project (Project B) only if you include the file in the project's own EGL build path.
  • The EGLAR file is available to another project (Project A) if you set the EGL build path for Project A to include the EGLAR file explicitly. This option is similar to accessing the EGLAR file from the file system. Project A then has access to the EGLAR file, regardless of settings in Project B, as long as the two projects are in the same workspace.
  • The complete project code for Project B, including the EGLAR file, is available to another project (Project A) only if you set the EGL build path for Project B to “export” the EGLAR file and only if you set the EGL build path for Project A so that Project A gains access to Project B.

For details on setting the build path and on making the code in the EGLAR file available indirectly, see “Editing the EGL build path.” For details on setting the eglpath option to access the EGLAR file from the EGL software development kit (EGLSDK), see “EGLSDK.”

A stand-alone EGLAR file that is referenced from an EGL build path is available for part resolution or generation. If the file was not imported and you want to generate parts from that file, a default build descriptor is not available, and you must use the generation wizard. However, if the file was imported, a default build descriptor is available and is identified in the nearest embedding project, package, or folder.

The use of a stand-alone EGLAR file has some implication for the workbench Search mechanism (menu option Search > Search):
  • The EGL search finds parts and other elements that are in IR files in the workspace. The import of an EGLAR file affects this search.
  • The file search finds source files in the workspace. The import of an EGLAR file has no effect on this search, even if the file includes source code for stand-alone function parts.

A build-path reference to an EGLAR file in the file system has no effect on either the EGL or file search. Neither the parts list nor parts reference features of the workbench are available in relation to EGLAR files.

Binary projects

An export task configures a binary project from a non-binary project. That task includes the EGLAR file in the build path of the binary project and exports the EGLAR file so that projects that reference the binary project can access the EGLAR file.

Only one EGLAR file should be in the binary project. That EGLAR file includes only IR files, and the project always includes source code and can include resources such as generated output and graphics files.

The presence of source files makes the following capabilities available:
  • You can open the source files in the EGL editor. The source code is read-only and is accessible either by opening the source file directly or by clicking on the related IR file.
  • The debugger can step into the parts in the source files.

You access a binary project by importing the project into your workspace. The binary project is then available for generation and deployment. Also, you can set the EGL build path of another project to access the binary project, for part resolution.

For details on setting the build path and on making the code in the binary project available indirectly, see “Editing the EGL build path.” Projects are not available to the EGL software development kit (EGLSDK).

If you generate parts from a binary project without using the generation wizard, the build descriptor is the default build descriptor in the binary project.

If you need to recreate the IR files in the binary project, update the source project on which the binary project is based and reexport that source project as a binary project. This action might be necessary if the binary project relies on the parts stored in a different source project, and some aspect of those parts changes.

Binary projects are included in both EGL searches and file searches.

The following restrictions are in effect:
  • In an EGL build path, reference a binary project as a project. Do not reference the embedded EGLAR file directly.
  • Although binary projects are meant to be read only, some workbench features let you update one. Do not update a binary project, as the behavior that results is likely to be different from what you expect. For example, do not import a stand-alone EGLAR file into a binary project.

Feedback