Compare Revisions

JAR Manifests

Revision 425629:

Revision 425629 by ethertank on

Revision 479249:

Revision 479249 by gps on

Title:
JAR Manifests
JAR Manifests
Slug:
JAR_Manifests
JAR_Manifests
Tags:
"Developing Mozilla","Build documentation"
"Build documentation"
Content:

Revision 425629
Revision 479249
t8      JAR Manifests are plaintext files in the mozilla build treet8      Documentation for JAR Manifests (jar.mn files) now lives <a
> that are used to package chrome files into the correct JARs, and> href="https://ci.mozilla.org/job/mozilla-central-docs/Build_Docu
> create <a href="/en-US/docs/Chrome_Registration">Chrome Registra>mentation/jar-manifests.html">in tree</a>.
>tion</a> manifests. JAR Manifests are named "jar.mn". 
9    </p>
10    <p>
11      jar.mn files are automatically processed by the build syste
>m when building a source directory that contains one. The jar.mn  
>is run through the <a href="/en-US/docs/Build/Text_Preprocessor"> 
>Build:Text Preprocessor</a> before being passed to the {{Source(" 
>config/JarMaker.py", "JarMaker.py script")}} (previously {{Source 
>("config/make-jars.pl", "make-jars script")}}) which processes th 
>e manifest. In order to have @variables@ expanded (such as @AB_CD 
>@) throughout the file, add the line '#filter substitution" at th 
>e top of your jar.mn file. The format of a jar.mn is fairly simpl 
>e; it consists of a heading specifying which JAR file is being pa 
>ckaged, followed by indented lines listing files and chrome regis 
>tration instructions. 
12    </p>
13    <p>
14      To see a simple jar.mn file at work, see {{Source("toolkit/
>profile/jar.mn")}}. A much more complex jar.mn is at {{Source("to 
>olkit/locales/jar.mn")}}. 
15    </p>
16    <h2 id="Shipping_Chrome_Files" name="Shipping_Chrome_Files">
17      Shipping Chrome Files
18    </h2>
19    <p>
20      To ship chrome files in a JAR, an indented line indicates a
> file to be packaged: 
21    </p>
22    <pre>
23&lt;jarfile&gt;.jar:
24  path/in/jar/file_name.xul     (source/tree/location/file_name.x
>ul) 
25</pre>
26    <p>
27      The source tree location may also be an "absolute" path (ta
>ken from the top of the mozilla/ source tree: 
28    </p>
29    <pre>
30  path/in/jar/file_name.xul     (/path/in/sourcetree/file_name.xu
>l) 
31</pre>
32    <p>
33      An asterisk marker at the beginning of the line indicates t
>hat the file should be processed by the <a href="/en-US/docs/Buil 
>d/Text_Preprocessor">text preprocessor</a> before being packaged: 
34    </p>
35    <pre>
36* path/in/jar/preprocessed.xul  (source/tree/location/file_name.x
>ul) 
37</pre>
38    <p>
39      A plus marker at the beginning of the line indicates that t
>he file should replace an existing file, even if the source file' 
>s timestamp isn't newer than the existing file: 
40    </p>
41    <pre>
42+ path/in/jar/file_name.xul     (source/tree/location/my_file_nam
>e.xul) 
43</pre>
44    <p>
45      Preprocessed files always replace existing files, to ensure
> that changes in <a href="/en-US/docs/Build/Text_Preprocessor#exp 
>and">#expand</a> or <a href="/en-US/docs/Build/Text_Preprocessor# 
>include">#include</a> directives are picked up, so <code>*+</code 
>> and <code>*</code> are equivalent. 
46    </p>
47    <p>
48      There is a special source-directory format for localized fi
>les (note the percent sign in the source file location): this for 
>mat reads localized.dtd from the "en-US" directory if building an 
> English version, and reads the file from the alternate localizat 
>ion source tree /l10n/&lt;locale&gt;/path/localized.dtd if buildi 
>ng a localized version. 
49    </p>
50    <pre>
51  locale/path/localized.dtd     (%localized/path/localized.dtd)
52</pre>
53    <h2 id="Register_Chrome" name="Register_Chrome">
54      Register Chrome
55    </h2>
56    <p>
57      <a href="/en-US/docs/Chrome_Registration">Chrome Registrati
>on</a> instructions are marked with a percent sign at the beginni 
>ng of the line, and must be part of the definition of a JAR file. 
> Any additional percents signs are replaced with an appropriate r 
>elative URL of the JAR file being packaged. 
58    </p>
59    <pre>
60% content global %path/in/jar/
61% overlay <a href="chrome://blah/content/blah.xul" rel="freelink"
>>chrome://blah/content/blah.xul</a> <a href="chrome://foo/content 
>/overlay.xul" rel="freelink">chrome://foo/content/overlay.xul</a> 
62</pre>
63    <p>
64      There are two possible locations for a manifest file. If th
>e chrome is being built into a standalone application, the jar.mn 
> processor creates a &lt;jarfilename&gt;.manifest next to the JAR 
> file itself. This is the default behavior. 
65    </p>
66    <p>
67      If the build Makefile specifies <a href="/en-US/docs/USE_EX
>TENSION_MANIFEST">USE_EXTENSION_MANIFEST</a> = 1, the jar.mn proc 
>essor creates a single chrome.manifest file suitable for register 
>ing chrome as an extension. If you need to call make-jars.pl dire 
>ctly, you can use the <code>-e</code> commandline option (setting 
> the environment variable doesn't work outside the normal build p 
>rocess). 

Back to History