Jump to: navigation, search

Difference between revisions of "FAQ What is the minimal Eclipse configuration?"

 
(refer to startup.jar for 3.2 and earlier)
 
(4 intermediate revisions by 3 users not shown)
Line 5: Line 5:
 
tiny Eclipse kernel consisting of the following:
 
tiny Eclipse kernel consisting of the following:
  
* <tt>startup.jar</tt>. This file contains a single class used to bootstrap the platform.  Its sole
+
* <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 find and invoke the plug-in responsible for starting the platform.
+
{|
</li>
+
|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.</li>
+
 
+
* <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.
+
</li>
+
 
+
* 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&#146;t need to know
+
anything about these plug-ins as they are used &#147;under the covers&#148;
+
to implement the runtime&#146;s functionality.
+
</li>
+
  
 +
* <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&#146;t need to know anything about these plug-ins as they are used &#147;under the covers&#148; to implement the runtime&#146;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&#146;s a little trick for figuring out what  
+
Here&#146;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.</li>
+
 
+
* 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.</li>
+
 
+
* Select '''Add Required Plug-ins'''.</li>
+
  
 +
* 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?]]
  
[[FAQ_What_is_a_configuration%3F]]
+
{{Template:FAQ_Tagline}}
 
+
[[FAQ_How_does_OSGi_and_the_new_runtime_affect_me%3F]]
+
 
+
<hr><font size=-2>This FAQ was originally published in [http://www.eclipsefaq.org Official Eclipse 3.0 FAQs]. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the [http://www.eclipse.org/legal/epl-v10.html Eclipse Public License v1.0].</font>
+

Latest revision as of 11:07, 14 August 2007

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.