If you are migrating from a version earlier than version
7, you can use the EGL V7.0 migration tool to migrate directly to
version 7.5.
Migrating from version 7.5 and later
To
move from version 7.5 to version 8.0, you do not need to run a migration
tool, but be aware of the following concerns:
- The directory structure for projects has changed in version 8.
With
version 8.0, EGL places generated Java code into the new EGLGen/JavaSource directory
at the top level of the project directory structure. EGL refreshes
this code each time you generate, including when you click .
Use the top-level JavaSource directory for Java code you have modified
by hand; the Clean command does not touch this
directory.
For Rich UI projects, you no longer use a generation
mode preference to determine whether you are generating for debug
or for runtime use. Instead, both types of code are generated automatically
into the EGLGen/JavaScript/Debug and EGLGen/JavaScript/Target directories.
If
you keep the version 7 directory structure, the project will work
normally in version 8. If you update the directory structure to the
new version 8 structure, you can no longer use the project in version
7.
Because of this change, it is more likely for developers
to create separate projects for Java™ generation
that merge into a single deployed project. If these projects have
cross-dependencies, you might need to change your Java build path. For more information, see Java build path.
- Rational® Business Developer version
8 requires Java 5 or later;
see "Java considerations in Rational Business Developer version
8" in this topic.
- The EGL NUMBER loose type has a new internal representation when
you generate for JavaScript.
No action is necessary in most cases because the default behavior
for EGL is to regenerate JavaScript automatically
when the EGL files are initially brought into version 8. If you disabled
the Generate after build preference for JavaScript, you must manually
generate all JavaScript files
that include the NUMBER type before using them in version 8. For more
information, see Loose types and Setting generation preferences.
- Best practice when moving to a new version is to create a new
workspace.
- If you use EGL Rich UI and do not update your widget libraries
when you move to version 8, be aware of possible compatibility issues.
For more information, see "Known compatibility in widget libraries"
in this topic.
Java considerations
in Rational Business Developer version
8
Version 8 requires Java 5
(also known as version 1.5.0) or later. This requirement is an upgrade
from version 7, which required Java version
1.4.0. Version 8 includes a Java Runtime
Environment (JRE) for Java 6.
This JRE is fully compatible with code generated by previous versions
of EGL, and you do not need to regenerate your existing EGL programs
because of the new JRE.
While you use EGL, you can choose to
run your Java batch programs,
and the Tomcat server, in the JRE that was installed with the product.
You might also choose to run those batch programs in any other Java 5 or higher JRE that you have
installed on your system, except for the JRE for WebSphere® Application Server.
That JRE is used exclusively with that product. You also need a JRE
to run generated code that you deploy outside of EGL or WebSphere Application Server.
You can choose any Java 5 or
later JRE for this purpose.
In most cases, the change causes
no problems. However, if you are committed to a corporate standard
of Java 1.4, do not migrate
to version 8.
Known compatibility in widget libraries
Best
practice when moving Rich UI projects to version 8 is to update the
widget libraries for those projects to the latest levels. For instructions
on how to import these projects, see Importing product-supplied projects.
If you
choose to use widget libraries from an older release, be aware that
only certain combinations of libraries have been tested. The following
table shows the versions of the widget libraries that are known to
be compatible. Other combinations are possible, but not guaranteed
to work efficiently together.
Table 1. Widget libraries known
to be compatible| Product version |
Rich UI widgets |
Dojo widgets |
Dojo runtime |
| 8.0 |
2.0.0 |
1.0.0 |
1.5 |
| 7.5.1.5 |
1.0.3 |
0.8.0* |
1.4 |
| 7.5.1.4 |
1.0.2 |
0.7.1* |
1.3.2 |
| 7.5.1.3 |
1.0.1 |
n/a |
n/a |
| 7.5.1.2 and earlier |
1.0.0 |
n/a |
n/a |
* Not officially supported; distributed through the EGL
Café.
Migrating from version 7.1, up to but not including
version 7.5
When you start the product, all of the projects
are checked to see if migration is needed. This check is also completed
when you import a project or check a project out of a source code
manager. If you must migrate, the workspace displays a message and
you can then select the specific projects and resources to migrate.
To
migrate from EGL version 7.1 to 7.5, the following code changes require
some files or projects:
- ExternalType function parameters require the in modifier.
- The path to Apache .jar files has changed.
- BIRT report files need ICU4J (International Components for Unicode
for Java) support.
Migrating from version 7.0, up to but not including
version 7.1
No program automates the migration from version
7.0 to version 7.1; in most cases, no migration is necessary. Migration
is necessary in two cases:
- If you use forms and you migrated to V7, you must change your
code before you run V7.1. Because EGL version 7 does not support forms,
most users with forms did not migrate to that version.
To migrate
forms from EGL V7 to V7.1, make the following changes:
- Add the @ operator to all printFloatingArea and screenFloatingArea properties.
- Place all of the @printFloatingArea complex
properties for a form inside the new printFloatingAreas property.
- Place all of the @screenFloatingArea complex
properties for a form inside the new screenFloatingAreas property.
- If you work with a web project that was generated for versions
7.0 to 7.0.0.3 and whose code runs in WebSphere Application Server and
accesses web services on all platforms, you must change the project.
If the project is to run on a server other than WebSphere Application Server,
no change is necessary.
To migrate a web project that uses
WebSphere Application Server from
EGL V7.0 to V7.1:
- Switch the class loader for the WAR file in the associated EAR
file to PARENT_FIRST:
- Double-click the projectNameEAR deployment
descriptor that is found in the root of the web project, where projectName is
the project name. This deployment descriptor is a J2EE deployment
descriptor, not an EGL deployment descriptor.
- In the deployment descriptor editor, click the Deployment tab.
- At the bottom of the Deployment page, find the Application section.
- From the Applications list, select the
WAR file that represents the web project.
- In the Classloader mode list, select PARENT_FIRST.
- Save and close the deployment descriptor.
- Open the Resource perspective and remove the following .jar files
from projectName/WebContent/WEB-INF/lib:
- axis.jar
- commons-discovery-0.2.jar
- commons-logging-1.0.4.jar
- eglwsdl.jar
- jaxrpc.jar
- saaj.jar
- wsdl4j-1.5.1.jar
- To ensure that the ServerType build descriptor option is set to
the appropriate version of WebSphere Application
Server, regenerate the project.
If you are migrating COBOL source or Rich UI projects,
you might need to make more changes. For details, see “COBOL-to-EGL
migration” and “Rich UI project migration.”