FAQ What is the minimal Eclipse configuration?

When you look at the collection of plug-ins in the Eclipse SDK, you're confronted with a daunting list. People wanting to create their own applications using Eclipse naturally ask how this list can be pared down so that only the essential plug-ins remain. If you take this exercise to its extreme, you'll be left with a tiny Eclipse kernel consisting of the following:

• org.eclipse.equinox.launcher. This plug-in contains essential classes to bootstrap the platform. Its purpose is to launch Eclipse from command line, webstart or by native launcher.

	org.eclipse.equinox.launcher.[ws].[os].[arch]. The platform specific fragments of the org.eclipse.equinox.launcher bundle contain an eclipse native shared library which is required by the native launcher. This shared library is also used to display the splash screen. If the native launcher is not being used, and a splash screen is not required, then this fragment can be excluded.
	startup.jar: In Eclipse 3.2 and earlier, the launcher plugin and fragment did not exist. Instead the startup.jar in the root of the install was responsible for bootstrapping the platform.

• Boot or configurator. A plug-in is responsible for finding and loading the plug-in configuration, the set of plug-ins and fragments that are going to be used in a given application. If no configuration exists, the configurator creates one that includes all plug-ins in the plugins directory on disk. The org.eclipse.core.boot plug-in implemented this functionality in Eclipse 2.1. In Eclipse 3.0, this task can be delegated to any plug-in but by default is done by the org.eclipse.update.configurator plug-in.

• org.eclipse.core.runtime. The runtime plug-in is the heart of the running Eclipse Platform. When it starts, this plug-in parses the plugin.xml files for all plug-ins in the configuration and builds an in-memory registry. The runtime plug-in also contains a number of useful utility classes that are used by almost all plug-ins: IPath, IStatus, IProgressMonitor, and so on. The runtime plug-in is also responsible for finding and invoking the chosen Eclipse application. Think of the runtime plug-in as the java.lang and java.util of the Eclipse Platform.

• Runtime plug-ins. The runtime uses a few plug-ins as implementation details that vary according to the release you are using. Up to and including Eclipse 2.1, the runtime plug-in needed an XML parser to parse the plugin.xml files. This parser is contained in the org.apache.xerces plug-in. In Eclipse 3.0, the runtime is built on top of a framework called OSGi, which is contained in three org.eclipse.osgi plug-ins. You generally don't need to know anything about these plug-ins as they are used "under the covers" to implement the runtime's functionality.

And there you have the minimal Eclipse configuration. Starting with this set, you can begin adding any plug-ins you need, such as SWT, JFace, and the platform UI, or other plug-ins you need to build your application.

Here's a little trick for figuring out what prerequisite plug-ins are needed by a given plug-in in the platform:

• Open the External Plug-ins and Fragments import wizard.
• In the list of plug-ins to import, select the one(s) you need for your application. For example, select org.eclipse.ui if you want generic UI features, or select org.eclipse.jdt.ui if you want the Java tools.
• Select Add Required Plug-ins.

You now you have a list of all prerequisites, recursively, for the plug-in you need. This trick is useful because the exact lists of prerequisites for a plug-in can vary between releases of Eclipse. If you ask someone to tell you exactly what plug-ins are needed for a particular kind of application, the answer is not likely to be valid across multiple release of Eclipse.

This same technique can also be used when the time comes to deploy your application. If you install your application plug-ins in the base development environment, you can then use the plug-in import wizard to recursively compute the required set of plug-ins for your application. This allows you to deploy your application with a minimal footprint, as all unused plug-ins are removed. However, it is possible that your end user may want to use functionality in plug-ins that are not even referenced by your application plug-ins, so be careful of what you chop out.

See Also:

• FAQ What is a configuration?
• FAQ How does OSGi and the new runtime affect me?

---

This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.