Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "FAQ What is the minimal Eclipse configuration?"
m (Translate character codes.) |
|||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | When you look at the collection of plug-ins in the Eclipse SDK, you | + | 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 | 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 | 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 | + | remain. If you take this exercise to its extreme, you'll be left with a |
tiny Eclipse kernel consisting of the following: | tiny Eclipse kernel consisting of the following: | ||
| − | * <tt> | + | * <tt>org.eclipse.equinox.launcher</tt>. This plug-in contains essential classes to bootstrap the platform. Its purpose is to launch Eclipse from command line, webstart or by native launcher. |
| − | purpose is to | + | {| |
| − | + | |width="25"| | |
| − | + | |<tt>org.eclipse.equinox.launcher.[ws].[os].[arch]</tt>. 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. | |
| − | * Boot or configurator. A plug-in is responsible for finding and loading | + | |- |
| − | the <i>plug-in configuration</i>, the set of plug-ins and | + | |width="25"| |
| − | fragments that are going to be used in a given application. If no configuration exists, | + | |<tt>startup.jar</tt>: 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. |
| − | the configurator creates one that includes all plug-ins | + | |} |
| − | in the <tt>plugins</tt> directory on disk. The <tt>org.eclipse.core.boot</tt> plug-in | + | * Boot or configurator. A plug-in is responsible for finding and loading the <i>plug-in configuration</i>, 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 <tt>plugins</tt> directory on disk. The <tt>org.eclipse.core.boot</tt> 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 <tt>org.eclipse.update.configurator</tt> 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 | + | |
| − | <tt>org.eclipse.update.configurator</tt> plug-in. | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | * <tt>org.eclipse.core.runtime</tt>. The runtime plug-in is the heart of the running Eclipse Platform. When it starts, this plug-in parses the <tt>plugin.xml</tt> 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: <tt>IPath</tt>, <tt>IStatus</tt>, <tt>IProgressMonitor</tt>, and so on. The runtime plug-in is also responsible for finding and invoking the chosen Eclipse <i>application</i>. Think of the runtime plug-in as the <tt>java.lang</tt> and <tt>java.util</tt> 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 <tt>plugin.xml</tt> files. This parser is contained in the <tt>org.apache.xerces</tt> plug-in. In Eclipse 3.0, the runtime is built on top of a framework called OSGi, which is contained in three <tt>org.eclipse.osgi</tt> 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 | And there you have the minimal Eclipse configuration. Starting with this set, you can begin | ||
| Line 46: | Line 23: | ||
plug-ins you need to build your application. | plug-ins you need to build your application. | ||
| − | Here | + | Here's a little trick for figuring out what prerequisite plug-ins are needed by a given plug-in in the platform: |
| − | 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 <tt>org.eclipse.ui</tt> if you want generic UI features, or select <tt>org.eclipse.jdt.ui</tt> 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. | You now you have a list of all prerequisites, recursively, for the plug-in you need. | ||
| Line 63: | Line 34: | ||
plug-ins are needed for a particular kind of application, the answer is not likely to | plug-ins are needed for a particular kind of application, the answer is not likely to | ||
be valid across multiple release of Eclipse. | be valid across multiple release of Eclipse. | ||
| − | |||
This same technique can also be | This same technique can also be | ||
| Line 73: | Line 43: | ||
functionality in plug-ins that are not even referenced by your application | functionality in plug-ins that are not even referenced by your application | ||
plug-ins, so be careful of what you chop out. | plug-ins, so be careful of what you chop out. | ||
| − | |||
| − | |||
== See Also: == | == See Also: == | ||
| + | *[[FAQ What is a configuration?]] | ||
| + | *[[FAQ How does OSGi and the new runtime affect me?]] | ||
| − | + | {{Template:FAQ_Tagline}} | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 15:32, 24 May 2017
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:
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.