You must include your new extension plugin in commerce-extensions/cm/ext-cm-webapp/feature.xml as follows, where PLUGIN_ID is the ID of your plugin:

<plugin id="PLUGIN_ID" download-size="0" install-size="0" version="0.0.0" unpack="false"/commerce-legacy/>
            

Your plugin ID can be found in your plugin's MANIFEST.MF file as the Bundle-SymbolicName, or in its pom.xml file as the artifactId.

If you are migrating a plugin from out of the box Commerce Manager to the extensions project, then you will need to remove the plugin from the out of the box Commerce Manager's feature.xml file in commerce-manager-client/com.elasticpath.cmclient.platform.feature/.

If your plugin depends on a bundle that is not registered in either out of the box or commerce-extensions' feature.xml , you need to add it as a dependency to commerce-extensions' feature.xml:

To do this, add a new plugin entry with the required Bundle ID. Ensure that you have the correct version or version range, as per Eclipse OSGi's Version Range Documentation.

The plugin being migrated must depend on the Eclipse RAP libraries instead of the Eclipse RCP libraries.

Edit your plugin's META-INF/MANIFEST.MF file with the following changes:

Your project should now compile when running mvn clean install from commerce-extensions. If this does not succeed, you may have to replace/remove other dependencies in the MANIFEST.MF file, or change specific Java imports to the RAP version.

All plugins must wait until a user session exists before running any display related code. Any calls in the AbstractEpUIPlugin.start() method that should run on the display thread need to be moved to an EarlyStartup class.

Early Startup classes should be registered in commerce-extensions' plugin.xml file using the org.eclipse.ui.startup extension point as follows:

<extension point="org.eclipse.ui.startup">  
    <startup class="com.elasticpath.cmclient.PACKAGE.PLUGIN_NAME"/commerce-legacy/>
</extension>
            

All plugins must wait until a user session exists before running any display related code. Any calls in the AbstractEpUIPlugin.start() method that should be run on the display thread will need to be deferred until after the user workbench is created.

To do this, register with CorePlugin using registerPreStartupCallback() or registerPostStartupCallback():

@Override
public void start(final BundleContext context) throws Exception {
  super.start(context);
  //If change set is disabled or then remove change set toolbar from the CoolBar
  CorePlugin.registerPostStartupCallback(new HideActionSetRunnable(changeSetHideCondition, ACTION_SET_ID));
}

NLS (localized) strings need to be converted from a single-user/single-locale to multiple-user/multiple-locale.

Prior to 7.0, strings were localized when the bundle was loaded, and were kept as constants of the Message class. As of 7.0, the localization strings are kept as instance fields of the Message class. An instance of the Message class must be created for each user, which is handled via the LocalizedMessagePostProcessor class.

Each Message class will need to implement a static Message.get() method, to expose the call to LocalizedMessagePostProcessor, which returns a specific instance that is localized to the users' locale.

All calls to the static Message class's static variables have to be converted to use the field variables.

For example, a new TermsAndConditionsMessages class could have the following method:

public String TermsAndConditionsDisplayMessage;

public static TermsAndConditionsMessages get() {
  return LocalizedMessagePostProcessor.getUTF8Encoded(TermsAndConditionsMessages.BUNDLE_NAME, TermsAndConditionsMessages.class);
}
            

A class uses it in the following manner:

layoutComposite.addLabelBold(TermsAndConditionsMessages.get().TermsAndConditionsDisplayMessage, data);
            

The PluginResource.properties file does not change for migrating to 7.0. However, one will be required for each locale, with the specific locale as a suffix.

For instance, the TermsAndConditions plugin has the files:

Replace all calls of Application.getInstance().getBean() with ServiceLocator.getService(). For example:

Pre-7.0:

private final ChangeSetService changeSetService = Application.getInstance().getBean(ContextIdNames.CHANGESET_SERVICE);
            

7.0:

private final ChangeSetService changeSetService = ServiceLocator.getService(ContextIdNames.CHANGESET_SERVICE);
            

Singletons are instances of a class that are shared across the entire JVM. They are only instantiated once, and all threads that use the class will use the same instance. This makes it easy to share data between threads.

However, this is a very bad design pattern when in a multiple-user application, as each user needs their own instance of specific classes.

The pre 7.0 CM client used Singletons throughout the code base. Any plugin that is to run in 7.0 CM must not contain singletons that are shared between users, otherwise, the users will encounter Threading issues.

Every plugin must convert their singletons into session instances, which are shared within a session, but not between different sessions.

For example, the `AdminUsersEventService` was converted from the Following pre-7.0:

public final class AdminUsersEventService {
              
private static AdminUsersEventService instance = new AdminUsersEventService();
              
/**
* Private constructor following the singleton pattern.
*/
  private AdminUsersEventService() {
    super();
  }
              
/**
* Gets a singleton instance of AdminUsersEventService.
*
* @return singleton instance of AdminUsersEventService
*/
  public static AdminUsersEventService getInstance() {
    if (AdminUsersEventService.instance == null) {
      AdminUsersEventService.instance = new AdminUsersEventService();
    }
      return AdminUsersEventService.instance;
    }
  }
            

To the following:

public final class AdminUsersEventService {
              
/**
* Private constructor following the session-singleton pattern.
*/
  private AdminUsersEventService() {
    super();
  }
              
/**
* Gets a session instance of AdminUsersEventService.
*
* @return session instance of AdminUsersEventService.
*/
public static AdminUsersEventService getInstance() {
  return CmSingletonUtil.getSessionInstance(AdminUsersEventService.class);
  }
}
            

If your plugin has an ImageRegistry, you need to ensure that it is Thread Safe. To do this, add a static initializer to the ImageRegistry class, and initialize all the images in the static block. Ensure that the getImage() method does not update any of the existing images.

If a unit test is using any of the new RAP functionality, such as instance field message strings, or calling the Display thread, they require an Eclipse RAP TestContext in order to pass.

To do this, ensure that there are no static initialization of fields, other than the TestContext, moving the field initialization to the setUp() method annotated with @Before. Next, include the TestContext as a field in the Unit test, as follows:

@Rule
public TestContext context = new TestContext();
            

and ensure that the TestContext is part of the plugins Require-Bundle section with the following entry:

org.eclipse.rap.rwt.testfixture;resolution:=optional
            

Ensure all Widgets, such as Buttons, Combos, TextFields, MenuItems are created through EpControlFactory so that test ids will be added to those widgets.