Migrating projects with a different targeted runtime into the workbench

The targeted runtime settings specify the application server and its version level of where you intend to run the project; for example, if the goal is to run the project on a WebSphere® Application Server V8.5, set the targeted runtime settings to WebSphere Application Server V8.5. When you specify the targeted runtime settings for a project, you can define the class path to the server. When you migrate a Java™ EE project from one workspace to another, the project may need to be set to a new target runtime because the server is no longer available. For example, if the current workbench has a WebSphere Application Server V9 and the project to migrate is target to WebSphere Application Server V8.5.

About this task

The class path of a project contains two class path entries. One entry is to Java developer kit and the other is to the server. The Java developer kit entry points to the directory that contains the JAR files that are necessary to support the Java developer kit version. The server entry points to the directory that contains the multiple public JAR files available in the selected server. The Java developer kit that is specified is the one required by the server. The project then compiles against the JAR files that are located in its class path.

When you migrate projects with a targeted runtime environment set to WebSphere Application Server from another workspace, the Workspace Migration wizard might prompt to update the targeted runtime environment to a matching or a higher version-level of WebSphere Application Server. If a higher version-level of WebSphere Application Server is selected, the specification-level of your project resources must be compatible in the higher selected version-level of the WebSphere Application Server. For details on the WebSphere Application Server and the specification-level it supports, see the Specifications and API documentation topic in the WebSphere Application Server documentation.

Restriction:
  • You can migrate a project by updating the targeted runtime environment to WebSphere Application Server traditional V9, or V8.5; however, this migration tool does not support updating the targeted runtime environment to any other servers, such as Apache Tomcat server.

Procedure

  1. Verify that your workspace contains a WebSphere Application Server entry in the runtime environments by completing the following steps:
    1. In theworkspace, select Window > Preferences > Server > Runtime Environments.
    2. On the Server Runtime Environments page and in the Server runtime environments list, verify that there is a WebSphere Application Server entry.
      If there is no WebSphere Application Server entry, see the Defining the server runtime environments preference topic for adding a runtime environment.
      Tip: A matching or the closest higher version-level of the WebSphere Application Server specified in this Server Runtime Environment preference page is going to be the default targeted runtime environment available for selection when you bring the migrated projects into the workspace.
  2. Select one of the following options to migrate your Java EE projects
    • You can use the Existing project into Workspace option.
    • You can use a source code management (SCM) system to load a project to the workbench.
    • You can permanently migrate your workspace on the same computer by starting the product with your workspace location. In this case, the settings in your Runtime Environments (Window > Preferences > Runtime Environments) are also preserved during the migration.
  3. When the Workspace Migration wizard opens, this wizard helps guide you through migrating your projects or workspace to the current release of this product. In the Workspace Migration page, click Next.
  4. In the Workspace projects which need migration page, select the projects that you want to migrate and click Next.
  5. The Migration Project Resources page lists the workspace files that are going to be affected by the migration. If your workspace is under a source code management (SCM) system, these files are going to be checked-out from the SCM system. Click Next.
  6. The Undefined Server Runtime page displays sets of projects that target a runtime environment that you must update to a server runtime environment defined in the current workbench.
    1. For each undefined server runtime environment, under the New Server Runtime column, use the controls to select a server runtime environment that is defined in the current workspace.
    2. If there is a no supported server runtime value displayed under the New Server Runtime column or you want to define a new WebSphere Application Server runtime environment for the current workspace, click the Search for Server Runtime Environments link to add the runtime environment to the current workbench.
      In the Search for Runtime Environments dialog box, specify the directory path to the server runtime environment, for example C:\Program Files\IBM\WebSphere\AppServer. Click OK. Under the New Server Runtime column, use the controls to select the newly created server runtime environment.
    3. Select the projects that you want to change to the new server runtime environment. Click Next.
  7. The page displays. When you are ready to begin the migration, click Finish.
  8. When your migration is completed, the window opens. Click OK.
  9. The Migration Results view lists the validator that were issued by the workbench during the migration. You can use this view to validate the consistency of the migrated projects in the current workspace.
  10. After your project is migrated, the targeted runtime environment is updated to your selected version-level of WebSphere Application Server. To verify, go to the Enterprise Explorer view in the Java EE perspective, right-click your migrated project, and select Properties > Targeted Runtimes. Notice the WebSphere Application Server vX check box is selected, where vX is the version-level of the WebSphere Application Server.

What to do next

Modifying artifact levels in the migrated project