Project Migration FAQ
What is project migration, and why is it required?
In MyEclipse 2013, we changed a significant portion of the project’s metadata to allow us to expand the capabilities of the IDE. For MyEclipse versions 2013 or higher to work with older projects, some migration of the older project metadata to the newer format is required, though not all projects require migration.
In addition to migrating project metadata, the migration process allows you to assign runtimes to your project where applicable or even help change the WebSphere version your project is targeted to, when dealing with WebSphere projects. Errors encountered during migration are better communicated in the migration wizard.
The migration process is not destructive, and migrated projects continue to work in prior versions of MyEclipse; changes made in newer MyEclipse versions will not appear in prior versions, of course.
The migration wizard appears automatically for projects requiring migration, but migration is not forced. Project migration status is displayed in the Workspace Migration view. Previous MyEclipse versions included three different migration wizards, one for older MyEclipse projects, one for WebTools projects, and one for RAD projects. Starting with MyEclipse 2013, the migration process is simplified, using only a single migration wizard and process. This ensures your project is ready to go, regardless of its source.
Do I need to do anything after the project is migrated?
Though we have endeavored to take all aspects of your project configuration into account, there might be rare cases in which the migration process fails to detect a particular technology or detects an incorrect framework version. To ensure that all aspects of the project were properly migrated, you can check the project’s MyEclipse>Project Facets property page.
MyEclipse 2013 introduced full support for Deployment Assembly, and correctly setting it up is one of the migration operations for projects migrated from MyEclipse 10.x and below. You can check to see that Deployment Assembly for your projects has been correctly configured. Please read MyEclipse Deployment Assembly for more information.
I have configured my server, but it’s not visible as a target runtime.
We are continually increasing the number of server connectors that can provide a target runtime. If your server connector does not provide a runtime, you can safely choose the Java EE Generic Runtime with a version appropriate for your project.
Myeclipse with WebSphere Support: After migrating a project from MyEclipse 10.x, in-workspace deployment mode doesn’t work.
In prior versions of MyEclipse, heuristics were used to determine which libraries should be deployed using the in-workspace deployment mode. Starting with MyEclipse 2013, the exact project structure as described in the project’s Deployment Assembly configuration is used in the in-workspace deployment mode. During migration from a previous version of MyEclipse, Deployment Assembly is configured to reflect the archive structure used for classic and enhanced deployments. As WebSphere places additional restrictions on the archive structure in the in-workspace mode, you might need to tweak the Deployment Assembly configuration. The most common issues are with class loading; WebSphere in the in-workspace mode requires the module hierarchy to follow Java EE rules strictly.
A project has a facet constraints error
Some projects might not be fit for automatic migration due to issues with facet configuration. The exact problem is reported in the problems list of the Migration wizard, and it must be resolved before the migration process can proceed. Usually the problem regards an incorrect version of the Java facet and happens only when the migration process is not able to correct the issue automatically. You are advised to close the Migration wizard and open the properties of the problematic project (right-click the project in package explorer, and select Properties from the menu). Navigate to the MyEclipse>Project Facets page and correct problems by changing facet versions or removing them. As a last resort, you can manually modify the facet configuration file, which is located in the .settings folder and named org.eclipse.wst.common.project.facet.core.xml.
Note: The .settings folder might not appear in the Package Explorer view; you will need to disable the.* resources filter to see it. To do so, click the white triangle (View menu) in the top-right corner of the Package Explorer view, and select Filters. Next, deselect the .* resources filter, and click OK. You should now be able to see the .settings file.
Version of Spring Facet could not be detected.
The migration process needs to detect the correct version of Spring support used by a project. If the process fails to detect the version based on containers used by the project, it tries to read it from the .springBeans file. If the file is missing, the migration process is unable to continue.
You need to manually create the file in the root of the project, before invoking the Migration wizard. To do so, right-click the project, and select New>File from the menu. Enter .springBeans as the file name, and click Finish. The .springBeans file editor should open. Paste the following code into it, and save the file.
<?xml version="1.0" encoding="UTF-8"?>
<beansProjectDescription>
<springVersion>2.0</springVersion>
</beansProjectDescription>
Now you can rerun the migration process by selecting MyEclipse>Migrate Projects from theMyEclipsemenu, or run the process from the Project Migration view.
Note: The .springBeans file might not appear in the Package Explorer view; you will need to disable the.* resources filter to see it. To do so, click the white triangle (View menu) in the top-right corner of the Package Explorer view and select Filters. Next, deselect the .* resources filter, and click OK. You should now be able to see the .springBeans file.
My problem is not listed.
If your problem is not listed, please post a message on our forums or contact support@genuitec.com.