load(":bazel_java_binary.bzl", "make_java_binary")

doc = """

""",

)

stardoc(

out = "rules_docs.out",

input = "rules.bzl",

rule_template = ":rule.vm",

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

to load native libraries.

</p>

<p>

<p>

A <code>deps</code> attribute is not allowed in a <code>java_binary</code> rule without

</p>

<p>The following code snippet illustrates a common mistake:</p>

<p>

This rule allows the use of precompiled <code>.jar</code> files as

<code>java_binary</code> rules.

</p>

<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

</p>

<h4 id="java_plugin_implicit_outputs">Implicit output targets</h4>

</ul>

<p>

for the addition of the <code>processor_class</code> argument.

</p>

<p>

See the section on <code>java_binary()</code> arguments. This rule also

to all test rules (*_test)</a>.

</p>

| <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-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` |

""",

file1 = "//java/docs:rules.md",

)

validate_configs()