Skip to main content

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.

Jump to: navigation, search

FAQ What is the plug-in manifest file (plugin.xml)?

Revision as of 19:26, 4 August 2010 by Mstorer3772.gmail.com (Talk | contribs) (Added i18n/l10n info, AKA "what the heck is that '%' for?!")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The plug-in manifest file, plugin.xml, describes how the plug-in extends the platform, what extensions it publishes itself, and how it implements its functionality. The manifest file is written in XML and is parsed by the platform when the plug-in is loaded into the platform. All the information needed to display the plug-in in the UI, such as icons, menu items, and so on, is contained in the manifest file. The implementation code, found in a separate Java JAR file, is loaded when, and only when, the plug-in has to be run. This concept is referred to as lazy loading. Here is the manifest file for a simple plug-in:

   <?xml version="1.0" encoding="UTF-8"?>
   <?eclipse version="3.0"?>
   <plugin id="com.xyz.myplugin" name="My Plugin" class="com.xyz.MyPlugin" version="1.0">
      <runtime>
         <library name="MyPlugin.jar"/>
      </runtime>
      <requires>
         <import plugin="org.eclipse.core.runtime"/>
      </requires>
   </plugin>

The processing instructions at the beginning specify the XML version and character encoding and that this plug-in was built for version 3.0 of the Eclipse Platform. The plugin element specifies the basic information about the plug-in, including, in this case, the optional class attribute to specify an instance of the Plugin class associated with this plug-in. Because it contains a subclass of Plugin, this plug-in must include a runtime element that specifies the JAR file that contains the code and a requires element to import the org.eclipse.core.runtime plug-in where the superclass resides. The manifest may also specify extensions and extension points associated with the plug-in. Of all this, only the plugin element with the id, name, and version attributes are required.


It is possible to internationalize the strings within a plugin by moving some of the xml attribute values into .properties files. The PDE will assist you in this as follows:

  1. Right click on the plugin.xml or MANIFEST.MF in the project view.
  2. Pick "PDE Tools->Externalize Strings...".
  3. Decide which strings should be moved and what their property names will be.
Helpful property names can make a translator's job much easier.
"command.name.3"? Not so much.

These externalized strings will appear in your plugin.xml as, for example:

<view
  category="fun.with.typesetting"
  name="%typesetter.view.name"
  class="...
/>

This would be paired with an entry in a .properties file (as of 3.6, Eclipse creates a file called "/myProject/OSGI-INF/l10n/bundle.properties") thusly:

typesetter.view.name=Etaoin Shrdlu

This properties file is also added to the list of bin.includes in your plugin's build.properties file.

A properly internationalized plugin can then be localized using plugin fragments.

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.

Back to the top