Minor documentation fixes

PiperOrigin-RevId: 678562013
Change-Id: I4a52cc458f4b72478c0286a7300cb1214d410d0d

java/bazel/rules/bazel_java_binary.bzl

@@ -381,7 +381,7 @@ def make_java_binary(executable):
       creates a self-contained jar file with a manifest that allows it to be run with the
       <code>java -jar</code> command or with the wrapper script's <code>--singlejar</code>
       option. Using the wrapper script is preferred to <code>java -jar</code> because it
-      also passes the <a href="${link java_binary.jvm_flags}">JVM flags</a> and the options
+      also passes the <a href="#java_binary-jvm_flags">JVM flags</a> and the options
       to load native libraries.
     </p>
     <p>
@@ -411,9 +411,9 @@ application (minus the extension). For example, if your entry point is called
 
 <p>
   A <code>deps</code> attribute is not allowed in a <code>java_binary</code> rule without
-  <a href="${link java_binary.srcs}"><code>srcs</code></a>; such a rule requires a
-  <a href="${link java_binary.main_class}"><code>main_class</code></a> provided by
-  <a href="${link java_binary.runtime_deps}"><code>runtime_deps</code></a>.
+  <a href="#java_binary-srcs"><code>srcs</code></a>; such a rule requires a
+  <a href="#java_binary-main_class"><code>main_class</code></a> provided by
+  <a href="#java_binary-runtime_deps"><code>runtime_deps</code></a>.
 </p>
 
 <p>The following code snippet illustrates a common mistake:</p>

java/bazel/rules/bazel_java_binary_nonexec.bzl

@@ -14,11 +14,8 @@
 
 """Defines a java_binary rule class that is non-executable.
 
-There are three physical rule classes for java_binary and we want all of them
+There are two physical rule classes for java_binary and we want both of them
 to have a name string of "java_binary" because various tooling expects that.
-But we also need the rule classes to be defined in separate files. That way the
-hash of their bzl environments will be different. See http://b/226379109,
-specifically #20, for details.
 """
 
 load(":bazel_java_binary.bzl", "make_java_binary")

java/bazel/rules/bazel_java_import.bzl

@@ -42,7 +42,7 @@ java_import = rule(
     doc = """
 <p>
   This rule allows the use of precompiled <code>.jar</code> files as
-  libraries for <code><a href="${link java_library}">java_library</a></code> and
+  libraries for <code><a href="#java_library">java_library</a></code> and
   <code>java_binary</code> rules.
 </p>
 

java/bazel/rules/bazel_java_plugin.bzl

@@ -128,7 +128,7 @@ java_plugin = rule(
   <code>java_binary</code> rule can run plugins by depending on them via the <code>plugins</code>
   attribute. A <code>java_library</code> can also automatically export plugins to libraries that
   directly depend on it using
-  <code><a href="${link java_library.exported_plugins}">exported_plugins</a></code>.
+  <code><a href="#java_library-exported_plugins">exported_plugins</a></code>.
 </p>
 
 <h4 id="java_plugin_implicit_outputs">Implicit output targets</h4>
@@ -137,7 +137,7 @@ java_plugin = rule(
     </ul>
 
 <p>
-  Arguments are identical to <a href="${link java_library}"><code>java_library</code></a>, except
+  Arguments are identical to <a href="#java_library"><code>java_library</code></a>, except
   for the addition of the <code>processor_class</code> argument.
 </p>
     """,

java/bazel/rules/bazel_java_test.bzl

@@ -54,7 +54,7 @@ test code. The test runner's main method is invoked instead of the main class be
 
 <p>
 See the section on <code>java_binary()</code> arguments. This rule also
-supports all <a href="${link common-definitions#common-attributes-tests}">attributes common
+supports all <a href="https://bazel.build/reference/be/common-definitions#common-attributes-tests">attributes common
 to all test rules (*_test)</a>.
 </p>
 
@@ -126,7 +126,7 @@ Whether to encode build information into the binary. Possible values:
 <ul>
 <li>
   <code>stamp = 1</code>: Always stamp the build information into the binary, even in
-  <a href="${link user-manual#flag--stamp}"><code>--nostamp</code></a> builds. <b>This
+  <a href="https://bazel.build/docs/user-manual#stamp"><code>--nostamp</code></a> builds. <b>This
   setting should be avoided</b>, since it potentially kills remote caching for the
   binary and any downstream actions that depend on it.
 </li>
@@ -136,7 +136,7 @@ Whether to encode build information into the binary. Possible values:
 </li>
 <li>
   <code>stamp = -1</code>: Embedding of build information is controlled by the
-  <a href="${link user-manual#flag--stamp}"><code>--[no]stamp</code></a> flag.
+  <a href="https://bazel.build/docs/user-manual#stamp"><code>--[no]stamp</code></a> flag.
 </li>
 </ul>
 <p>Stamped binaries are <em>not</em> rebuilt unless their dependencies change.</p>

java/docs/BUILD.bazel

@@ -16,7 +16,7 @@ bzl_library(
 )
 
 stardoc(
-    name = "rule_docs",
+    name = "rules_docs",
     out = "rules_docs.out",
     input = "rules.bzl",
     rule_template = ":rule.vm",

java/docs/rules.md

@@ -52,7 +52,7 @@ java_binary(<a href="#java_binary-name">name</a>, <a href="#java_binary-deps">de
       creates a self-contained jar file with a manifest that allows it to be run with the
       <code>java -jar</code> command or with the wrapper script's <code>--singlejar</code>
       option. Using the wrapper script is preferred to <code>java -jar</code> because it
-      also passes the <a href="${link java_binary.jvm_flags}">JVM flags</a> and the options
+      also passes the <a href="#java_binary-jvm_flags">JVM flags</a> and the options
       to load native libraries.
     </p>
     <p>
@@ -82,9 +82,9 @@ application (minus the extension). For example, if your entry point is called
 
 <p>
   A <code>deps</code> attribute is not allowed in a <code>java_binary</code> rule without
-  <a href="${link java_binary.srcs}"><code>srcs</code></a>; such a rule requires a
-  <a href="${link java_binary.main_class}"><code>main_class</code></a> provided by
-  <a href="${link java_binary.runtime_deps}"><code>runtime_deps</code></a>.
+  <a href="#java_binary-srcs"><code>srcs</code></a>; such a rule requires a
+  <a href="#java_binary-main_class"><code>main_class</code></a> provided by
+  <a href="#java_binary-runtime_deps"><code>runtime_deps</code></a>.
 </p>
 
 <p>The following code snippet illustrates a common mistake:</p>
@@ -159,7 +159,7 @@ java_import(<a href="#java_import-name">name</a>, <a href="#java_import-deps">de
 
 <p>
   This rule allows the use of precompiled <code>.jar</code> files as
-  libraries for <code><a href="${link java_library}">java_library</a></code> and
+  libraries for <code><a href="#java_library">java_library</a></code> and
   <code>java_binary</code> rules.
 </p>
 
@@ -313,7 +313,7 @@ java_plugin(<a href="#java_plugin-name">name</a>, <a href="#java_plugin-deps">de
   <code>java_binary</code> rule can run plugins by depending on them via the <code>plugins</code>
   attribute. A <code>java_library</code> can also automatically export plugins to libraries that
   directly depend on it using
-  <code><a href="${link java_library.exported_plugins}">exported_plugins</a></code>.
+  <code><a href="#java_library-exported_plugins">exported_plugins</a></code>.
 </p>
 
 <h4 id="java_plugin_implicit_outputs">Implicit output targets</h4>
@@ -322,7 +322,7 @@ java_plugin(<a href="#java_plugin-name">name</a>, <a href="#java_plugin-deps">de
     </ul>
 
 <p>
-  Arguments are identical to <a href="${link java_library}"><code>java_library</code></a>, except
+  Arguments are identical to <a href="#java_library"><code>java_library</code></a>, except
   for the addition of the <code>processor_class</code> argument.
 </p>
 
@@ -423,7 +423,7 @@ test code. The test runner's main method is invoked instead of the main class be
 
 <p>
 See the section on <code>java_binary()</code> arguments. This rule also
-supports all <a href="${link common-definitions#common-attributes-tests}">attributes common
+supports all <a href="https://bazel.build/reference/be/common-definitions#common-attributes-tests">attributes common
 to all test rules (*_test)</a>.
 </p>
 
@@ -479,7 +479,7 @@ java_test(
 | <a id="java_test-plugins"></a>plugins |  Java compiler plugins to run at compile-time. Every <code>java_plugin</code> specified in this attribute will be run whenever this rule is built. A library may also inherit plugins from dependencies that use <code><a href="#java_library.exported_plugins">exported_plugins</a></code>. Resources generated by the plugin will be included in the resulting jar of this rule.   | <a href="https://bazel.build/concepts/labels">List of labels</a> | optional |  `[]`  |
 | <a id="java_test-resource_strip_prefix"></a>resource_strip_prefix |  The path prefix to strip from Java resources. <p> If specified, this path prefix is stripped from every file in the <code>resources</code> attribute. It is an error for a resource file not to be under this directory. If not specified (the default), the path of resource file is determined according to the same logic as the Java package of source files. For example, a source file at <code>stuff/java/foo/bar/a.txt</code> will be located at <code>foo/bar/a.txt</code>. </p>   | String | optional |  `""`  |
 | <a id="java_test-runtime_deps"></a>runtime_deps |  Libraries to make available to the final binary or test at runtime only. Like ordinary <code>deps</code>, these will appear on the runtime classpath, but unlike them, not on the compile-time classpath. Dependencies needed only at runtime should be listed here. Dependency-analysis tools should ignore targets that appear in both <code>runtime_deps</code> and <code>deps</code>.   | <a href="https://bazel.build/concepts/labels">List of labels</a> | optional |  `[]`  |
-| <a id="java_test-stamp"></a>stamp |  Whether to encode build information into the binary. Possible values: <ul> <li>   <code>stamp = 1</code>: Always stamp the build information into the binary, even in   <a href="${link user-manual#flag--stamp}"><code>--nostamp</code></a> builds. <b>This   setting should be avoided</b>, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. </li> <li>   <code>stamp = 0</code>: Always replace build information by constant values. This   gives good build result caching. </li> <li>   <code>stamp = -1</code>: Embedding of build information is controlled by the   <a href="${link user-manual#flag--stamp}"><code>--[no]stamp</code></a> flag. </li> </ul> <p>Stamped binaries are <em>not</em> rebuilt unless their dependencies change.</p>   | Integer | optional |  `0`  |
+| <a id="java_test-stamp"></a>stamp |  Whether to encode build information into the binary. Possible values: <ul> <li>   <code>stamp = 1</code>: Always stamp the build information into the binary, even in   <a href="https://bazel.build/docs/user-manual#stamp"><code>--nostamp</code></a> builds. <b>This   setting should be avoided</b>, since it potentially kills remote caching for the   binary and any downstream actions that depend on it. </li> <li>   <code>stamp = 0</code>: Always replace build information by constant values. This   gives good build result caching. </li> <li>   <code>stamp = -1</code>: Embedding of build information is controlled by the   <a href="https://bazel.build/docs/user-manual#stamp"><code>--[no]stamp</code></a> flag. </li> </ul> <p>Stamped binaries are <em>not</em> rebuilt unless their dependencies change.</p>   | Integer | optional |  `0`  |
 | <a id="java_test-test_class"></a>test_class |  The Java class to be loaded by the test runner.<br/> <p>   By default, if this argument is not defined then the legacy mode is used and the   test arguments are used instead. Set the <code>--nolegacy_bazel_java_test</code> flag   to not fallback on the first argument. </p> <p>   This attribute specifies the name of a Java class to be run by   this test. It is rare to need to set this. If this argument is omitted,   it will be inferred using the target's <code>name</code> and its   source-root-relative path. If the test is located outside a known   source root, Bazel will report an error if <code>test_class</code>   is unset. </p> <p>   For JUnit3, the test class needs to either be a subclass of   <code>junit.framework.TestCase</code> or it needs to have a public   static <code>suite()</code> method that returns a   <code>junit.framework.Test</code> (or a subclass of <code>Test</code>).   For JUnit4, the class needs to be annotated with   <code>org.junit.runner.RunWith</code>. </p> <p>   This attribute allows several <code>java_test</code> rules to   share the same <code>Test</code>   (<code>TestCase</code>, <code>TestSuite</code>, ...).  Typically   additional information is passed to it   (e.g. via <code>jvm_flags=['-Dkey=value']</code>) so that its   behavior differs in each case, such as running a different   subset of the tests.  This attribute also enables the use of   Java tests outside the <code>javatests</code> tree. </p>   | String | optional |  `""`  |
 | <a id="java_test-use_launcher"></a>use_launcher |  Whether the binary should use a custom launcher.<br><br><p>If this attribute is set to false, the <a href="${link java_binary.launcher}">launcher</a> attribute  and the related <a href="${link user-manual#flag--java_launcher}"><code>--java_launcher</code></a> flag will be ignored for this target.   | Boolean | optional |  `True`  |
 | <a id="java_test-use_testrunner"></a>use_testrunner |  Use the test runner (by default <code>com.google.testing.junit.runner.BazelTestRunner</code>) class as the main entry point for a Java program, and provide the test class to the test runner as a value of <code>bazel.test_suite</code> system property.<br><br><br/> You can use this to override the default behavior, which is to use test runner for <code>java_test</code> rules, and not use it for <code>java_binary</code> rules.  It is unlikely you will want to do this.  One use is for <code>AllTest</code> rules that are invoked by another rule (to set up a database before running the tests, for example).  The <code>AllTest</code> rule must be declared as a <code>java_binary</code>, but should still use the test runner as its main entry point.<br><br>The name of a test runner class can be overridden with <code>main_class</code> attribute.   | Boolean | optional |  `True`  |

test/BUILD.bazel

@@ -55,7 +55,7 @@ diff_test(
     cp bazel-bin/java/docs/rules_docs.out java/docs/rules.md
     """,
     file1 = "//java/docs:rules.md",
-    file2 = "//java/docs:rule_docs",
+    file2 = "//java/docs:rules_docs",
 )
 
 validate_configs()