JAR Manifests are plaintext files in the mozilla build tree that are used to package chrome files into the correct JARs, and create Chrome Registration manifests. JAR Manifests are named "jar.mn".
The format of a jar.mn is fairly simple, though it has grown over time. Every jar.mn has a line which indicates which JAR file is being packaged:
Shipping Chrome Files
To ship chrome files in a JAR, an indented line indicates a file to be packaged:
The source tree location may also be an "absolute" path (taken from the top of the mozilla/ source tree:
There is a special source-directory format for localized files (note the percent sign): this format reads localized.dtd from the "en-US" directory if building an English version, and reads the file from the alternate localization source tree /l10n/<locale>/path/localized.dtd if building a localized version.
Chrome registration instructions are marked with a percent sign at the beginning of the line. Any additional percents signs are replaced with an appropriate relative URL of the JAR file being packaged.
% content global %path/in/jar/ % overlay chrome://blah/content/blah.xul chrome://foo/content/overlay.xul
There are two possible locations for a manifest file. If the chrome is being built into a standalone application, the jar.mn processor creates a <jarfilename>.manifest next to the JAR file itself. This is the default behavior.
If the build Makefile specifies USE_EXTENSION_MANIFEST = 1, the jar.mn processor creates a single chrome.manifest file suitable for registering chrome as an extension.
Finally, in order to be backwards-compatible with the old contents.rdf chrome registration scheme, whenever the jar.mn processor encounters a contents.rdf file, it will automatically add the path of that contents.rdf to the chrome/installed-chrome.txt file. If this behavior is undesirable (for instance, when packaging an extension XPI), set NO_JAR_AUTO_REG = 1 in the makefile to suppress this default behavior.