Eclipse platform and plug-in development (category)

The Eclipse target platform

The Eclipse IDE has been a plug-in environment since its early versions. It has become an application platform since Eclipse 3 with the adoption of the OSGi modular system. Equinox, a project developed by the foundation, is the OSGi framework implementation that runs the Eclipse IDE. Anyone developing an Eclipse plug-in also develops an OSGi bundle. As this technology is about modules, an important architectural point here is dependencies (between modules).

Other platforms than the Eclipse IDE adopt a similar organization, i.e. a set of OSGi bundles as components, here are three examples:

JOnas
Glassfish
Eclipse Virgo

Some components available as Eclipse plug-ins can be deployed in JOnas or Glassfish, for example the OSGi distribution of EclipseLink. But this is not true for all plug-ins. As Eclipse is an IDE, dependencies on graphical elements come easily. Therefore most Eclipse plug-ins can't be deployed in other environments.

This is the reason why it is important to choose the right target platform when developing an Eclipse plug-in. A blog post by Holger Staudacher explains how to define a runtime for a Jersey/JAX-RS application.

This post is interesting on the definition point of view. A simple element is missing: how to use the defined target runtime when developing an Eclipse plug-in ? A tutorial by Lars Vogel details such a procedure (in section 3).

EMF model change listener

As explained in the EclipseZone forum exchange on the topic, two strategies are available to listen to changes on an EMF model:

EContentAdapter (from the EMF core)
ResourceSetListener (from the EMF/transaction)

The EContentAdapter notifies of change on any EMF object (EObject). This requires to have a direct access on the object, what does not help much to listen on third-party changes (external editor on anything else). A tutorial by Lars Vogel details how to use it.

The ResourceSetListener solution, far more complete on the transaction point of view, helps to listen on external editor changes. It is observer pattern. An access to the editor's editing domain is required, it must be of type TransactionalEditingDomain in order to expose the registration method.

Programmatically refactor with the JDT

Using the internal rename package is not a very good idea (discouraged access warning). There is an official documentation on that topic. A stackoverflow exchange also mentions interesting informations.

Decoding simple JDT signatures

The JDT sometimes returns simplified type signatures, for example the IMethod#getParameterTypes() method can return values such as QString instead of java.lang.String.

To decode such values, the org.eclipse.jdt.core.Signature class provides utility functions. Signature#getSignatureSimpleName(String) transforms QString into the simple name, i.e. String.

To get the full name, the containing type allows to resolve the simple name. IType#resolveType(String) transforms this simple name using the imports of the containing type. The result is an array with two dimensions. The first one is for the case where there are multiple answers possible. The second one separates the name of the package and the simple name.

The following code returns the first full name of a method return type:

	String name = method.getReturnType();
	String simpleName = Signature.getSignatureSimpleName(name);
	IType type = method.getDeclaringType();
	String[][] allResults = type.resolveType(simpleName);
	String fullName = null;
	if(allResults != null) {
		String[] nameParts = allResults[0];
		if(nameParts != null) {
			fullName = new String();
			for(int i=0 ; i < nameParts.length ; i++) {
				if(fullName.length() > 0) {
					fullName += '.';
				}
				if(nameParts[i] != null) {
					fullName += nameParts[i];
				}
			}
		}
	}
	return name;

An exchange on stackoverflow details the code for parameters types full names.