Skip to main content

Platform and Equinox API

Platform Changes

ECommandService and EHandlerService released as API The following API have been made official.
The bundle org.eclipse.e4.core.commands was updated to version 1.0.0.
Embedded Jetty server updated to version 10.x Jetty Server used by the help system is updated to version 10.x. As this version requires Servlet API 4.x the opportunity is used to move to the new Jakarta Servlet name of the library. Bundle symbolic name becomes jakarta.servlet-api from the old javax.servlet one. One of the Jetty bundles org.eclipse.jetty.continuation has been removed from Jetty 10 releases thus it's no longer part of Eclipse Platform content too.
Register Model fragments via Manifest header It is now possible to register model fragments via the newly introduced Manifest Header Model-Fragment. This way it is not necessary to create a plugin.xml that contains an extension to the extension point org.eclipse.e4.workbench.model.

To register a fragment via Manifest header, you can now simply add an entry similar to the following snippet to the MANIFEST.MF of the contributing bundle:

Model-Fragment: fragment.e4xmi;apply=always

The apply attribute is optional and defaults to always. It can have the same values as specified in the extension point:
  • always: each time the application started potentially replacing existing model elements and loosing information stored
  • initial: only when coming from a none persistent state
  • notexists: only if the given element does not exist already in the model
Register Model processor via DS It is now possible to register model processors as declarative service. The model processor needs to implement the service interface IModelProcessorContribution to get registered. This way it is not necessary to create a plugin.xml that contains an extension to the extension point org.eclipse.e4.workbench.model.

The model processor is registered via DS, the execution is triggered via the Eclipse injection mechanism. The processor execution at registration time needs to be placed in a method annotated with @Execute. Additionally it is possible to add a method annotated with @PreDestroy which gives the opportunity to cleanup in case the bundle that provides the model processor contribution is stopped.

@Component
public class ExampleProcessorContribution implements IModelProcessorContribution {

    @Execute
    public void execute() {
        System.out.println("Processor executed");
    }

    @PreDestroy
    public void preDestroy() {
        System.out.println("Processor killed");
    }
}
      

It is also possible to re-use existing model processor POJO implementations and register them via an IModelProcessorContribution. For this the method getProcessorClass() needs to be overridden to return the class of the model processor POJO. In this case there is no support for handling the stopping of the contributing bundle.

@Component
public class ExampleProcessorContribution implements IModelProcessorContribution {

    @Override
    public Class<?> getProcessorClass() {
        return ExampleProcessor.class;
    }
}
      
The IModelProcessorContribution supports two service properties for configuration:
  • beforefragment: specifies if the processor has to be invoked before model fragments are added. If not specified it defaults to true.
  • apply: defines in which case a processor is run. If not specified it defaults to always.
    Possible values are:
    • always: each time the application started
    • initial: only when coming from a none persistent state
@Component(property = {
    IModelProcessorContribution.BEFORE_FRAGMENT_PROPERTY_PREFIX + "false",
    IModelProcessorContribution.APPLY_PROPERTY_PREFIX + "initial"
})
public class ExampleProcessorContribution implements IModelProcessorContribution { ... }
      

You can also specify model elements that should be added to the context that is used to invoke the processor. This is necessary as the processor is invoked on application context level. To specify such model elements you need to override the method getModelElements()

@Component(property = {
		IModelProcessorContribution.BEFORE_FRAGMENT_PROPERTY_PREFIX + "false"
})
public class ExampleProcessorContribution implements IModelProcessorContribution {

    @Execute
    public void execute(@Named("org.eclipse.example.partstack") MPartStack myTest) {
        System.out.println("Processor executed: " + myTest.getElementId());
    }

    @Override
    public List<ModelElement> getModelElements() {
        return Arrays.asList(new ModelElement("org.eclipse.example.partstack"));
    }
}
      
New static methods to ease Status creation

New API methods in Status (org.eclipse.core.runtime.Status) makes it easier and less verbose to make Status object for error handling. There are methods called info, warning and error for creating status objects of those severities. These methods simplify the API by using StackWalker API (introdcued in Java 9) to automatically determine the Plug-in ID. The existing constructors for more fine grained control still continue to exist and may be the most suitable when using Status objects in non-error handling cases as explicitly passing the plug-in id in by String can be faster than automatically determining it.

A couple of examples of before and after with the new API:
  • Creating a warning Status

    Existing API:
    IStatus status = new Status(IStatus.WARNING, UIPlugin.PLUGIN_ID, IStatus.OK, message, null);
    New static helper methods:
    IStatus status = Status.warning(message);
  • Throwing a CoreException:

    Existing API:
    throw new CoreException(new Status(IStatus.ERROR, UIPlugin.PLUGIN_ID, message, e));
    New static helper methods:
    throw new CoreException(Status.error(message, e));

SWT Changes

Option to disable "Insert Emoji" menu entry on Linux On Linux it is now possible to disable the Insert Emoji context menu entry of text fields, on GTK 3.22.20 and upward. This can be done with the following command line argument for Eclipse:

-DSWT_GTK_INPUT_HINT_NO_EMOJI=true

Equinox p2 Changes

Verify PGP signatures during installation When installing some artifact with p2, and those artifacts have the pgp.signatures property set, the signatures will be verified during installation and installation will fail if a signature couldn't be verified.

Reasons of failures would be:

  • Signature is not well formatted (it must be armoured PGP blocks) or is intrisically wrong (eg the signature has been modified in a way that makes it totally invalid).
  • No public key was found that matches the signature. Public keys are expected to be provided as value of the pgp.publicKeys property either on the artifact metadata or, usually better, on the artifact repository, in armoured form.
  • The signature and a matching public key were found, but the verification process shows that the signature is incorrect. This usually means the signature was meant for another artifact.
Each one of those reasons will make the build fail, as they are security threats. It is assumed that any signed artifact can be successfully verified for all given signatures to continue installation.

Previous Up Next

Back to the top