Structure of an installable bundle

  • Revision slug: Bundles
  • Revision title: Structure of an installable bundle
  • Revision id: 72259
  • Created:
  • Creator: Benjamin Smedberg
  • Is current revision? No
  • Comment

Revision Content

XULRunner applications, extensions, and themes all share a common directory structure, and in some cases the same bundle can be used as a standalone XULRunner application as well as an installable application extension. The basic structure of bundles may include any of the following files:

/install.rdf                        Extension/Theme Install Manifest
/application.ini                    Application Launch Manifest
/components/*                       Component and XPT Files      (>=1.7)
/defaults/preferences/*.js          Default Preferences          (>=1.7)
/plugins/*                          NPAPI Plugins                (>=1.8)
/chrome.manifest                    Chrome Registration Manifest (>=1.8)
/chrome/icons/default/*             Window Icons                 (>=1.8)

Of course, an extension need not (and normally won't) have all of these directories. Themes are limited for security reasons, and can normally only provide a chrome.manifest which registers the theme and a JAR file.

Platform-specific Subdirectories

In some cases a single extension or application may wish to include binary component or plugins for multiple platforms. To facilitate this, the extension/app loader has special sub-directories specifically for platform-specific files. The "XPCOM_ABI" is defined during the toolkit build process to a value unique for each operating system/processor architecture/compiler. All of the files which are loaded from the main extension directory are loaded from the subdirectory

/platform/{XPCOM_ABI}

if it exists. For example, if a plugin vendor wanted to make a plugin available for consumer computers running Linux, Macintosh, and Windows, it would provide the following files:

/platform/Linux_x86-gcc3/plugins/libMyPlugin.so
/platform/WINNT_x86-msvc/plugins/MyPlugin.dll
/platform/Darwin_ppc-gcc3/plugins/libMyPlugin.dylib

Because XPT files are not platform-specific, any associated XPT files would go in the generic components directory:

/components/MyPlugin.xpt

If an extension has non-binary platform-specific code (such as code which uses the windows registry from script), it can also use just the operating system identifier as a platform-subdirectory:

/platform/WINNT/components/registerDoctype.js

Application-specific Extension Files

In addition to the extension files listed above, applications may read additional files from extensions. For example, Firefox 1.1 and greater will read search plugins from

/searchplugins/*.src

Revision Source

<p>XULRunner applications, extensions, and themes all share a common directory structure, and in some cases the same bundle can be used as a standalone XULRunner application as well as an installable application extension. The basic structure of bundles may include any of the following files:
</p>
<pre class="eval">/<a href="en/Install.rdf">install.rdf</a>                        <i>Extension/Theme Install Manifest</i>
/application.ini                    <i>Application Launch Manifest</i>
/components/*                       <i>Component and XPT Files</i>      (&gt;=1.7)
/defaults/preferences/*.js          <i>Default Preferences</i>          (&gt;=1.7)
/plugins/*                          <i>NPAPI Plugins</i>                (&gt;=1.8)
/chrome.manifest                    <i>Chrome Registration Manifest</i> (&gt;=1.8)
/chrome/icons/default/*             <i>Window Icons</i>                 (&gt;=1.8)
</pre>
<p>Of course, an extension need not (and normally won't) have all of these directories. Themes are limited for security reasons, and can normally only provide a <a href="en/Chrome_Registration">chrome.manifest</a> which registers the theme and a JAR file.
</p>
<h3 name="Platform-specific_Subdirectories"> Platform-specific Subdirectories </h3>
<p>In some cases a single extension or application may wish to include binary component or plugins for multiple platforms. To facilitate this, the extension/app loader has special sub-directories specifically for platform-specific files. The "XPCOM_ABI" is defined during the toolkit build process to a value unique for each operating system/processor architecture/compiler. All of the files which are loaded from the main extension directory are loaded from the subdirectory
</p>
<pre class="eval">/platform/<i>{XPCOM_ABI}</i>
</pre>
<p>if it exists. For example, if a plugin vendor wanted to make a plugin available for consumer computers running Linux, Macintosh, and Windows, it would provide the following files:
</p>
<pre class="eval">/platform/Linux_x86-gcc3/plugins/libMyPlugin.so
/platform/WINNT_x86-msvc/plugins/MyPlugin.dll
/platform/Darwin_ppc-gcc3/plugins/libMyPlugin.dylib
</pre>
<p>Because XPT files are not platform-specific, any associated XPT files would go in the generic components directory:
</p>
<pre class="eval">/components/MyPlugin.xpt
</pre>
<p>If an extension has non-binary platform-specific code (such as code which uses the windows registry from script), it can also use just the operating system identifier as a platform-subdirectory:
</p>
<pre class="eval">/platform/WINNT/components/registerDoctype.js
</pre>
<h3 name="Application-specific_Extension_Files"> Application-specific Extension Files </h3>
<p>In addition to the extension files listed above, applications may read additional files from extensions. For example, Firefox 1.1 and greater will read search plugins from
</p>
<pre class="eval">/searchplugins/*.src
</pre>
Revert to this revision