|
2
|
1 |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
|
2 |
<html>
|
|
|
3 |
<head>
|
|
|
4 |
<title>Doc Process Notes</title>
|
|
|
5 |
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
|
6 |
</head>
|
|
|
7 |
|
|
|
8 |
<body>
|
|
|
9 |
<h3><a name="REGEXP"></a><br>
|
|
|
10 |
REGEXP</h3>
|
|
|
11 |
<p> REGEXP is a list of wildcard patterns that determines which packages listed
|
|
|
12 |
in CORE_PKGS.gmk go into which summary-table on the main API index page. It
|
|
|
13 |
was motivated by the need to divide the world into "core packages"
|
|
|
14 |
(java.*) and "extension packages" (javax.*). In time, the distinction
|
|
|
15 |
went away. The whole table is now called "Platform Packages"--which
|
|
|
16 |
eliminated the need for this list of regular expressions. But it lingered on,
|
|
|
17 |
accreting all of the packages in the JVM, one by one. I pruned it back to "*",
|
|
|
18 |
so it now covers every package in the Java platform API docs. If some separation
|
|
|
19 |
is needed in the future, it can grow back into a colon-separated list, starting
|
|
|
20 |
with this, which is in all respects equivalent to "*" at this point
|
|
|
21 |
in time:</p>
|
|
|
22 |
<blockquote>
|
|
|
23 |
<pre>REGEXP = "java.*:javax.*:org.ietf*:org.omg.</pre>
|
|
|
24 |
</blockquote>
|
|
|
25 |
<h3><a name="releaseTargets"></a><br>
|
|
|
26 |
Release Targets</h3>
|
|
|
27 |
<p> (Thanks to Kelly O'Hair for this info.)</p>
|
|
|
28 |
<p> The <tt>rel-coredocs</tt> and <tt>rel-docs</tt> targets were added by Eric
|
|
|
29 |
Armstrong. <tt>rel-coredocs</tt> assumes the kind of large, 32-bit machine used
|
|
|
30 |
in the javapubs group's docs-release process. It specifies memory settings accordingly
|
|
|
31 |
to maximize performance.</p>
|
|
|
32 |
<p> The performance settings, like the sanity check, are most important for the
|
|
|
33 |
core docs--the platform APIs. Running javadoc on those APIs takes a significant
|
|
|
34 |
amount of time and memory. Setting the initial heap size as large as possible
|
|
|
35 |
is important to prevent thrashing as the heap grows. Setting the maximum as
|
|
|
36 |
large as necessary is also important to keep the job from failing.</p>
|
|
|
37 |
<blockquote>
|
|
|
38 |
<p> <tt>-J-Xmx512</tt> sets a maximum of 512, which became necessary in 6.0<br>
|
|
|
39 |
<tt>-J-Xms256</tt> sets starting size to 256 (default is 8)</p>
|
|
|
40 |
</blockquote>
|
|
|
41 |
<p> <tt>rel-coredocs</tt> also includes a sanity check to help ensure that <tt>BUILD_NUMBER</tt>
|
|
|
42 |
and <tt>MILESTONE</tt> are specified properly when docs are built outside of
|
|
|
43 |
the normal release engineering process, with the intention of releasing them
|
|
|
44 |
on the web or in a downloaded docs bundle. (When invoked in release engineering's
|
|
|
45 |
control build, the values are always set properly. But when the targets are
|
|
|
46 |
run by themselves, they default to b00 and "internal"--which silently
|
|
|
47 |
sabotage the result of a build that can take many hours to complete.</p>
|
|
|
48 |
</body>
|
|
|
49 |
</html>
|