For stable release documentation, please use the "Versioned docs" drop-down. The default view reflects the latest version at HEAD.

Diese Seite wurde von der Cloud Translation API übersetzt.

Java-Regeln

Problem melden Quelle ansehen

Regeln

java_binary
java_import
java_library
java_lite_proto_library
java_proto_library
java_test
java_package_configuration
java_plugin
java_runtime
java_toolchain

java_binary

Regelquelle ansehen

java_binary(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, output_licenses, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)

Erstellt ein Java-Archiv („JAR-Datei“) sowie ein Wrapper-Shell-Script mit dem gleichen Namen wie die Regel. Das Wrapper-Shell-Skript verwendet einen Klassenpfad, der unter anderem eine JAR-Datei für jede Bibliothek enthält, von der die Binärdatei abhängt. Beim Ausführen des Wrapper-Shell-Skripts hat jede nicht leere JAVABIN-Umgebungsvariable Vorrang vor der Version, die über das Flag --java_runtime_version von Looker angegeben wurde.

Das Wrapper-Skript akzeptiert mehrere eindeutige Flags. Unter //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt finden Sie eine Liste der konfigurierbaren Flags und Umgebungsvariablen, die vom Wrapper akzeptiert werden.

Implizite Ausgabeziele

name.jar: Ein Java-Archiv, das die Klassendateien und andere Ressourcen enthält, die den direkten Abhängigkeiten der Binärdatei entsprechen.
name-src.jar: Ein Archiv mit den Quellen („Quell-JAR-Datei“).
name_deploy.jar: Ein Java-Archiv, das für die Bereitstellung geeignet ist (nur erstellt, wenn dies explizit angefordert wird).
Wenn Sie das <name>_deploy.jar-Ziel für Ihre Regel erstellen, wird eine eigenständige JAR-Datei mit einem Manifest erstellt, das die Ausführung mit dem Befehl java -jar oder der Option --singlejar des Wrapper-Skripts ermöglicht. Das Wrapper-Skript wird gegenüber java -jar bevorzugt, da es auch die JVM-Flags und die Optionen zum Laden nativer Bibliotheken übergibt.

Die Bereitstellungs-JAR-Datei enthält alle Klassen, die von einem Classloader gefunden werden würden, der den Klassenpfad im Wrapper-Skript des Binärprogramms von Anfang bis Ende durchsucht hat. Außerdem enthält es die nativen Bibliotheken, die für Abhängigkeiten erforderlich sind. Diese werden zur Laufzeit automatisch in die JVM geladen.

Wenn Ihr Ziel ein Launcher-Attribut angibt, ist die _deploy.jar-Datei keine normale JAR-Datei, sondern eine native Binärdatei. Dieser enthält den Launcher sowie alle nativen (C++) Abhängigkeiten Ihrer Regel, die alle in einer statischen Binärdatei verknüpft sind. Die Byte der eigentlichen JAR-Datei werden an diese native Binärdatei angehängt, wodurch ein einzelnes Binär-Blob erstellt wird, das sowohl die ausführbare Datei als auch den Java-Code enthält. Sie können die resultierende JAR-Datei wie jede native Binärdatei ausführen.
name_deploy-src.jar: Ein Archiv mit den Quellen, die bei der vorübergehenden Schließung des Ziels erfasst wurden. Diese stimmen mit den Klassen in deploy.jar überein, es sei denn, JAR-Dateien haben keine übereinstimmende Quell-JAR-Datei.

Ein deps-Attribut ist in einer java_binary-Regel ohne srcs nicht zulässig. Eine solche Regel erfordert eine main_class von runtime_deps.

Das folgende Code-Snippet veranschaulicht einen häufigen Fehler:

java_binary(
    name = "DontDoThis",
    srcs = [
        ...,
        "GeneratedJavaFile.java",  # a generated .java file
    ],
    deps = [":generating_rule"],  # rule that generates that file
)

Gehen Sie stattdessen so vor:

java_binary(
    name = "DoThisInstead",
    srcs = [
        ...,
        ":generating_rule",
    ],
)

Argumente

Attribute
`name`	Name: erforderlich Ein eindeutiger Name für dieses Ziel. Es empfiehlt sich, den Namen der Quelldatei zu verwenden, die der Haupteinstiegspunkt der Anwendung ist (ohne die Erweiterung). Wenn Ihr Einstiegspunkt beispielsweise `Main.java` heißt, könnte Ihr Name `Main` sein.
`deps`	Liste mit Labels; Standardwert ist `[]` Die Liste anderer Bibliotheken, die mit dem Ziel verknüpft werden sollen. Allgemeine Kommentare zu `deps` finden Sie unter Typische Attribute, die von den meisten Build-Regeln definiert werden.
`srcs`	Liste mit Labels; Standardwert ist `[]` Die Liste der Quelldateien, die zum Erstellen des Ziels verarbeitet werden. Dieses Attribut ist fast immer erforderlich, siehe Ausnahmen unten. Quelldateien vom Typ `.java` werden kompiliert. Bei generierten `.java`-Dateien ist es im Allgemeinen empfehlenswert, hier den Namen der Generierungsregel und nicht den Namen der Datei selbst anzugeben. Dies verbessert nicht nur die Lesbarkeit, sondern macht die Regel auch robuster gegen zukünftige Änderungen: Wenn durch die Generierungsregel in Zukunft verschiedene Dateien generiert werden, müssen Sie nur eine Stelle korrigieren: die `outs` der Generierungsregel. Sie sollten die Generierungsregel nicht in `deps` auflisten, da es sich um eine Nulloperation handelt. Quelldateien vom Typ `.srcjar` werden entpackt und kompiliert. (Dies ist nützlich, wenn Sie eine Reihe von `.java`-Dateien mit einer Genrule generieren müssen.) Regeln: Wenn durch die Regel (normalerweise `genrule` oder `filegroup`) eine der oben aufgeführten Dateien generiert wird, werden diese so verwendet wie für Quelldateien beschrieben. Dieses Argument ist fast immer erforderlich, außer wenn ein `main_class`-Attribut eine Klasse im Laufzeitklassenpfad angibt oder Sie das Argument `runtime_deps` angeben.
`resources`	Liste mit Labels; Standardwert ist `[]` Eine Liste der Datendateien, die in einer Java-JAR-Datei enthalten sein sollen. Wenn Ressourcen angegeben sind, werden sie in der JAR-Datei zusammen mit den üblichen `.class`-Dateien gebündelt, die bei der Kompilierung erstellt werden. Der Speicherort der Ressourcen in der JAR-Datei wird durch die Projektstruktur bestimmt. Bazel sucht zuerst nach dem Standardverzeichnislayout von Maven (ein Verzeichnis namens "src" gefolgt von einem Enkelpfad des Verzeichnisses "resources"). Wenn diese nicht gefunden wird, sucht Looker nach dem obersten Verzeichnis namens „java“ oder „javatests“. Wenn sich eine Ressource beispielsweise unter `<workspace root>/x/java/y/java/z` befindet, lautet der Pfad der Ressource `y/java/z`. Diese Heuristik kann nicht überschrieben werden. Mit dem Attribut `resource_strip_prefix` kann jedoch ein bestimmtes alternatives Verzeichnis für Ressourcendateien angegeben werden. Ressourcen können Quelldateien oder generierte Dateien sein.
`classpath_resources`	Liste mit Labels; Standardwert ist `[]` VERWENDEN SIE DIESE OPTION NICHT, ES ES IST NUR, WENN DIESE NOCH NICHT MEHR DURCHFÜHRUNG IST.) Eine Liste der Ressourcen, die sich auf der Stammebene des Java-Baums befinden müssen. Der einzige Zweck dieses Attributs besteht darin, Bibliotheken von Drittanbietern zu unterstützen, deren Ressourcen genau wie `"myconfig.xml"` im Klassenpfad zu finden sind. Aufgrund der Gefahr von Namespace-Konflikten ist dies nur bei Binärdateien und nicht bei Bibliotheken zulässig.
`create_executable`	Boolesch; nicht konfigurierbar; Standardwert ist `True` Verworfen, verwenden Sie stattdessen `java_single_jar`.
`deploy_env`	Liste mit Labels; Standardwert ist `[]` Eine Liste anderer `java_binary`-Ziele, die die Bereitstellungsumgebung für dieses Binärprogramm darstellen. Lege dieses Attribut fest, wenn du ein Plug-in erstellst, das von einem anderen `java_binary` geladen wird. Wenn dieses Attribut festgelegt wird, werden alle Abhängigkeiten aus dem Laufzeitklassenpfad (und der Bereitstellungs-JAR-Datei) dieser Binärdatei ausgeschlossen, die von dieser Binärdatei und den in `deploy_env` angegebenen Zielen gemeinsam genutzt werden.
`deploy_manifest_lines`	Liste mit Strings; Standardwert ist `[]` Eine Liste von Zeilen, die der Datei `META-INF/manifest.mf` hinzugefügt werden sollen, die für das Ziel `_deploy.jar` generiert wurde. Der Inhalt dieses Attributs unterliegt nicht* der Ersetzung „Variable machen“.
`javacopts`	Liste mit Strings; Standardwert ist `[]` Zusätzliche Compiler-Optionen für diese Bibliothek. Unterliegt der Ersetzung „Make variable“ und der Bourne-Shell-Tokenisierung. Diese Compiler-Optionen werden nach den globalen Compiler-Optionen an javac übergeben.
`jvm_flags`	Liste mit Strings; Standardwert ist `[]` Eine Liste der Flags, die in das Wrapper-Skript eingebettet werden sollen, das für die Ausführung dieser Binärdatei generiert wurde. Unterliegt der Ersetzung $(location) und „Make variable“ sowie der Bourne-Shell-Tokenisierung. Das Wrapper-Skript für eine Java-Binärdatei enthält eine CLASSPATH-Definition (um alle abhängigen JAR-Dateien zu finden) und ruft den richtigen Java-Interpreter auf. Die vom Wrapper-Skript generierte Befehlszeile enthält den Namen der Hauptklasse gefolgt von einem `"$@"`, sodass Sie nach dem Klassennamen weitere Argumente übergeben können. Argumente, die für das Parsen durch die JVM gedacht sind, müssen jedoch vor dem Klassennamen in der Befehlszeile angegeben werden. Der Inhalt von `jvm_flags` wird dem Wrapper-Skript hinzugefügt, bevor der Klassenname aufgeführt wird. Beachten Sie, dass dieses Attribut keine Auswirkungen auf `*_deploy.jar`-Ausgaben hat.
`launcher`	Label; Standardwert ist `None` Geben Sie ein Binärprogramm an, das zum Ausführen Ihres Java-Programms anstelle des normalen `bin/java`-Programms, das im JDK enthalten ist, verwendet wird. Das Ziel muss ein `cc_binary` sein. Jeder `cc_binary`, der die Java Invocation API implementiert, kann als Wert für dieses Attribut angegeben werden. Standardmäßig verwendet Looker den normalen JDK-Launcher (bin/java oder java.exe). Das zugehörige Qwiklabs-Flag `--java_launcher` wirkt sich nur auf die Ziele `java_binary` und `java_test` aus, für die kein `launcher`-Attribut angegeben wurde. Ihre nativen Abhängigkeiten (C++, SWIG, JNI) werden abhängig davon, ob Sie den JDK-Launcher oder einen anderen Launcher verwenden, unterschiedlich aufgebaut: Wenn Sie den normalen JDK Launcher (Standardeinstellung) verwenden, werden native Abhängigkeiten als gemeinsam genutzte Bibliothek mit dem Namen `{name}_nativedeps.so` erstellt. Dabei ist `{name}` das Attribut `name` dieser java_binary-Regel. Nicht verwendeter Code wird durch die Verknüpfung in dieser Konfiguration nicht entfernt. Wenn Sie einen anderen Launcher verwenden, sind native (C++) Abhängigkeiten statisch zu einer Binärdatei mit dem Namen `{name}_nativedeps` verknüpft, wobei `{name}` das Attribut `name` dieser java_binary-Regel ist. In diesem Fall entfernt die Verknüpfung jeden Code, der ihrer Ansicht nach nicht verwendet wird, aus dem resultierenden Binärprogramm. Das bedeutet, dass C++-Code, auf den nur über JNI zugegriffen wird, möglicherweise nur verknüpft wird, wenn das `cc_library`-Ziel `alwayslink = 1` angibt. Wenn Sie einen anderen Launcher als den JDK-Standard-Launcher verwenden, ändert sich das Format der `*_deploy.jar`-Ausgabe. Weitere Informationen finden Sie in der java_binary-Hauptdokumentation.
`main_class`	String; der Standardwert ist `""` Name der Klasse mit der Methode `main()`, die als Einstiegspunkt verwendet werden soll. Wenn eine Regel diese Option verwendet, ist keine `srcs=[...]`-Liste erforderlich. Daher kann mit diesem Attribut eine ausführbare Datei aus einer Java-Bibliothek erstellt werden, die bereits eine oder mehrere `main()`-Methoden enthält. Der Wert dieses Attributs ist ein Klassenname, keine Quelldatei. Die Klasse muss zur Laufzeit verfügbar sein: Sie kann durch diese Regel (aus `srcs`) kompiliert oder durch direkte oder Transitive Abhängigkeiten (über `runtime_deps` oder `deps`) bereitgestellt werden. Wenn die Klasse nicht verfügbar ist, schlägt das Binärprogramm zur Laufzeit fehl. Es gibt keine Build-Zeitprüfung.
`plugins`	Liste mit Labels; Standardwert ist `[]` Java-Compiler-Plug-ins, die bei der Kompilierung ausgeführt werden. Jeder in diesem Attribut angegebene `java_plugin` wird bei jeder Erstellung dieser Regel ausgeführt. Eine Bibliothek kann auch Plug-ins von Abhängigkeiten übernehmen, die `exported_plugins` verwenden. Vom Plug-in generierte Ressourcen werden in die resultierende JAR-Datei dieser Regel aufgenommen.
`resource_jars`	Liste mit Labels; Standardwert ist `[]` Eingestellt: Verwenden Sie stattdessen „java_import und deps“ oder „runtime_deps“.
`resource_strip_prefix`	String; der Standardwert ist `""` Das Pfadpräfix, das aus den Java-Ressourcen entfernt werden soll. Wenn dieses Pfadpräfix angegeben wird, wird es aus jeder Datei im Attribut `resources` entfernt. Es ist ein Fehler, wenn sich eine Ressourcendatei nicht in diesem Verzeichnis befindet. Falls nicht angegeben (Standardeinstellung), wird der Pfad der Ressourcendatei nach derselben Logik wie das Java-Paket der Quelldateien bestimmt. Die Quelldatei unter `stuff/java/foo/bar/a.txt` befindet sich beispielsweise unter `foo/bar/a.txt`.
`runtime_deps`	Liste mit Labels; Standardwert ist `[]` Bibliotheken, die nur für die finale Binärdatei oder den Test zur Laufzeit verfügbar gemacht werden sollen. Wie die normale `deps` werden auch diese im Laufzeitklassenpfad angezeigt, jedoch im Gegensatz zu ihnen nicht im Klassenpfad der Kompilierungszeit. Hier sollten Abhängigkeiten aufgeführt sein, die nur zur Laufzeit benötigt werden. Tools zur Abhängigkeitsanalyse sollten Ziele ignorieren, die sowohl in `runtime_deps` als auch in `deps` enthalten sind.
`stamp`	Ganzzahl; der Standardwert ist `-1` Gibt an, ob Build-Informationen in der Binärdatei codiert werden sollen. Mögliche Werte: `stamp = 1`: Stempelt die Build-Informationen immer in die Binärdatei ab, auch in `--nostamp`-Builds. Diese Einstellung sollte vermieden werden, da sie möglicherweise das Remote-Caching für das Binärprogramm und alle davon abhängigen nachgelagerten Aktionen beendet. `stamp = 0`: Build-Informationen werden immer durch konstante Werte ersetzt. Dies ermöglicht ein gutes Caching von Build-Ergebnissen. `stamp = -1`: Das Einbetten von Build-Informationen wird durch das Flag `--[no]stamp` gesteuert. Gestempelte Binärprogramme werden nicht neu erstellt, es sei denn, ihre Abhängigkeiten ändern sich.
`use_launcher`	Boolescher Wert; Standardwert ist `True` Gibt an, ob das Binärprogramm einen benutzerdefinierten Launcher verwenden soll. Ist dieses Attribut auf „false“ gesetzt, werden das Attribut Launcher und das zugehörige Flag `--java_launcher` für dieses Ziel ignoriert.
`use_testrunner`	Boolescher Wert; Standardwert ist `False` Verwenden Sie die Klasse des Test-Runners (standardmäßig `com.google.testing.junit.runner.BazelTestRunner`) als Haupteinstiegspunkt für ein Java-Programm und geben Sie die Testklasse als Wert des Systemattributs `bazel.test_suite` an den Test-Runner an. Damit können Sie das Standardverhalten überschreiben: Die Verwendung des Test-Runners für `java_test`-Regeln und nicht für `java_binary`-Regeln. Es ist unwahrscheinlich, dass Sie dies tun werden. Eine Verwendung ist für `AllTest`-Regeln, die von einer anderen Regel aufgerufen werden (z. B. um eine Datenbank vor dem Ausführen der Tests einzurichten). Die `AllTest`-Regel muss als `java_binary` deklariert werden, sollte aber trotzdem den Test-Runner als Haupteinstiegspunkt verwenden. Der Name einer Test-Runner-Klasse kann mit dem Attribut `main_class` überschrieben werden.

java_import

Regelquelle ansehen

java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)

Diese Regel ermöglicht die Verwendung vorkompilierter .jar-Dateien als Bibliotheken für java_library- und java_binary-Regeln.

Beispiele


    java_import(
        name = "maven_model",
        jars = [
            "maven_model/maven-aether-provider-3.2.3.jar",
            "maven_model/maven-model-3.2.3.jar",
            "maven_model/maven-model-builder-3.2.3.jar",
        ],
    )

Argumente

Attribute
`name`	Name: erforderlich Ein eindeutiger Name für dieses Ziel.
`deps`	Liste mit Labels; Standardwert ist `[]` Die Liste anderer Bibliotheken, die mit dem Ziel verknüpft werden sollen. Siehe java_library.deps.
`data`	Liste mit Labels; Standardwert ist `[]` Die Liste der Dateien, die von dieser Regel zur Laufzeit benötigt werden.
`add_exports`	Liste mit Strings; Standardwert ist `[]` Dieser Bibliothek erlauben, auf die angegebene `module` oder `package` zuzugreifen. Dies entspricht den javac- und JVM --add-exports=-Flags.
`add_opens`	Liste mit Strings; Standardwert ist `[]` Erlaubt dieser Bibliothek, nachvollziehbar auf die angegebenen `module` oder `package` zuzugreifen. Dies entspricht den javac- und JVM-Flags --add-opens=.
`constraints`	Liste mit Strings; Standardwert ist `[]` Zusätzliche Einschränkungen für diese Regel als Java-Bibliothek.
`exports`	Liste mit Labels; Standardwert ist `[]` Ziele, die Nutzern dieser Regel zur Verfügung gestellt werden sollen. Siehe java_library.exports.
`jars`	Liste der Labels; erforderlich Die Liste der JAR-Dateien, die für Java-Ziele bereitgestellt werden, die von diesem Ziel abhängen.
`neverlink`	Boolescher Wert; Standardwert ist `False` Verwenden Sie diese Bibliothek nur für die Kompilierung und nicht zur Laufzeit. Dies ist hilfreich, wenn die Bibliothek während der Ausführung von der Laufzeitumgebung bereitgestellt wird. Beispiele für Bibliotheken wie diese sind IDE APIs für IDE-Plug-ins oder `tools.jar` für alles, was auf einem Standard-JDK ausgeführt wird.
`proguard_specs`	Liste mit Labels; Standardwert ist `[]` Dateien, die als Proguard-Spezifikation verwendet werden sollen. Diese beschreiben die von Proguard zu verwendenden Spezifikationen. Wenn angegeben, werden sie in Abhängigkeit von dieser Bibliothek zu jedem `android_binary`-Ziel hinzugefügt. Die hier enthaltenen Dateien dürfen nur idempotente Regeln enthalten, nämlich "-dontnote", "-dontwarn", "assumenosideeffects" und Regeln, die mit "-keep" beginnen. Andere Optionen können nur in den proguard_specs von `android_binary` angezeigt werden, um eine nicht tautologische Zusammenführung zu ermöglichen.
`runtime_deps`	Liste mit Labels; Standardwert ist `[]` Bibliotheken, die nur für die finale Binärdatei oder den Test zur Laufzeit verfügbar gemacht werden sollen. Siehe java_library.runtime_deps.
`srcjar`	Label; Standardwert ist `None` Eine JAR-Datei, die Quellcode für die kompilierten JAR-Dateien enthält.

java_library

Regelquelle ansehen

java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)

Mit dieser Regel werden Quellen in einer .jar-Datei kompiliert und verknüpft.

Implizite Ausgaben

libname.jar: Ein Java-Archiv, das die Klassendateien enthält.
libname-src.jar: Ein Archiv mit den Quellen („Quell-JAR-Datei“).

Argumente

Attribute
`name`	Name: erforderlich Ein eindeutiger Name für dieses Ziel.
`deps`	Liste mit Labels; Standardwert ist `[]` Die Liste der Bibliotheken, die mit dieser Bibliothek verknüpft werden sollen. Allgemeine Kommentare zu `deps` finden Sie unter Typische Attribute, die von den meisten Build-Regeln definiert werden. Die JAR-Dateien, die von den in `deps` aufgeführten `java_library`-Regeln erstellt wurden, befinden sich im Klassenpfad zur Kompilierungszeit dieser Regel. Außerdem erfolgt das vorübergehende Schließen ihrer `deps`, `runtime_deps` und `exports` auf dem Laufzeitklassenpfad. Im Gegensatz dazu sind Ziele im Attribut `data` in den Runfiles enthalten, aber weder im Klassenpfad für die Kompilierungszeit noch im Laufzeitklassenpfad.
`srcs`	Liste mit Labels; Standardwert ist `[]` Die Liste der Quelldateien, die zum Erstellen des Ziels verarbeitet werden. Dieses Attribut ist fast immer erforderlich, siehe Ausnahmen unten. Quelldateien vom Typ `.java` werden kompiliert. Bei generierten `.java`-Dateien ist es im Allgemeinen empfehlenswert, hier den Namen der Generierungsregel und nicht den Namen der Datei selbst anzugeben. Dies verbessert nicht nur die Lesbarkeit, sondern macht die Regel auch weniger an zukünftigen Änderungen: Wenn die Generierungsregel in Zukunft unterschiedliche Dateien generiert, müssen Sie nur eine Stelle korrigieren: die `outs` der Generierungsregel. Sie sollten die Generierungsregel nicht in `deps` auflisten, da es sich um eine Nulloperation handelt. Quelldateien vom Typ `.srcjar` werden entpackt und kompiliert. (Dies ist nützlich, wenn Sie eine Reihe von `.java`-Dateien mit einer Genrule generieren müssen.) Regeln: Wenn durch die Regel (normalerweise `genrule` oder `filegroup`) eine der oben aufgeführten Dateien generiert wird, werden diese so verwendet wie für Quelldateien beschrieben. Quelldateien vom Typ `.properties` werden als Ressourcen behandelt. Alle anderen Dateien werden ignoriert, solange mindestens eine Datei des oben beschriebenen Dateityps vorhanden ist. Andernfalls wird ein Fehler ausgegeben. Dieses Argument ist fast immer erforderlich, es sei denn, Sie geben das Argument `runtime_deps` an.
`data`	Liste mit Labels; Standardwert ist `[]` Die Liste der Dateien, die diese Bibliothek zur Laufzeit benötigt. Allgemeine Kommentare zu `data` finden Sie unter Typische Attribute, die von den meisten Build-Regeln definiert werden. Beim Erstellen einer `java_library` legt Looker diese Dateien nirgendwo hin. Wenn die `data`-Dateien generiert sind, werden sie von Qwiklabs generiert. Beim Erstellen eines Tests, der von dieser `java_library` abhängig ist, kopiert oder verknüpft Qwiklabs die `data`-Dateien in den Runfiles-Bereich.
`resources`	Liste mit Labels; Standardwert ist `[]` Eine Liste der Datendateien, die in einer Java-JAR-Datei enthalten sein sollen. Ressourcen können Quelldateien oder generierte Dateien sein. Wenn Ressourcen angegeben sind, werden sie in der JAR-Datei zusammen mit den üblichen `.class`-Dateien gebündelt, die bei der Kompilierung erstellt werden. Der Speicherort der Ressourcen in der JAR-Datei wird durch die Projektstruktur bestimmt. Bali sucht zuerst nach dem Standardverzeichnis-Layout von Maven (ein „src“-Verzeichnis gefolgt von einem Enkelzeichen des „resources“-Verzeichnisses). Wenn diese nicht gefunden wird, sucht Looker nach dem obersten Verzeichnis namens "java" oder "javatests". Wenn sich eine Ressource beispielsweise unter `<workspace root>/x/java/y/java/z` befindet, ist der Pfad der Ressource `y/java/z`. Diese Heuristik kann nicht überschrieben werden. Mit dem Attribut `resource_strip_prefix` kann jedoch ein bestimmtes alternatives Verzeichnis für Ressourcendateien angegeben werden.
`add_exports`	Liste mit Strings; Standardwert ist `[]` Dieser Bibliothek erlauben, auf die angegebene `module` oder `package` zuzugreifen. Dies entspricht den javac- und JVM --add-exports=-Flags.
`add_opens`	Liste mit Strings; Standardwert ist `[]` Erlaubt dieser Bibliothek, nachvollziehbar auf die angegebenen `module` oder `package` zuzugreifen. Dies entspricht den javac- und JVM-Flags --add-opens=.
`bootclasspath`	Label; Standardwert ist `None` Eingeschränkte API, nicht verwenden!
`exported_plugins`	Liste mit Labels; Standardwert ist `[]` Die Liste der `java_plugin`s (z.B. Annotationsprozessoren), die in Bibliotheken exportiert werden sollen, die direkt von dieser Bibliothek abhängen. Die angegebene Liste von `java_plugin`s wird auf jede Bibliothek angewendet, die direkt von dieser Bibliothek abhängt, so als hätte diese Bibliothek diese Labels explizit in `plugins` deklariert.
`exports`	Liste mit Labels; Standardwert ist `[]` Exportierte Bibliotheken. Wenn Sie Regeln hier auflisten, sind sie für übergeordnete Regeln verfügbar, als ob sie explizit von diesen Regeln abhängig wären. Dies gilt nicht für reguläre (nicht exportierte) `deps`. Zusammenfassung: Eine Regel X kann auf den Code in Y zugreifen, wenn ein Abhängigkeitspfad zwischen ihnen besteht, der mit einer `deps`-Kantenlinie gefolgt von null oder mehr `exports`-Kanten beginnt. Sehen wir uns einige Beispiele an. Es wird angenommen, dass A von B und B von C abhängt. In diesem Fall ist C eine transitive Abhängigkeit von A. Wenn Sie also die Quellen von C ändern und A neu erstellen, wird alles korrekt neu erstellt. A kann jedoch keine Klassen in C verwenden. Dazu muss entweder A entweder C in seiner `deps` deklarieren oder B kann es für A (und alles, was von A abhängig sein kann) einfacher machen, indem C in seinem `exports`-Attribut (B) deklariert wird. Das Schließen exportierter Bibliotheken ist für alle direkt übergeordneten Regeln möglich. Nehmen wir ein etwas anderes Beispiel: A hängt von B ab, B hängt von C und D ab und exportiert auch C, aber nicht D. Jetzt hat A Zugriff auf C, aber nicht auf D. Wenn C und D nun einige Bibliotheken (C' und D') exportiert haben, könnte A nur auf C', aber nicht auf D' zugreifen. Wichtig: Eine exportierte Regel ist keine reguläre Abhängigkeit. Wenn B in Bezug auf das vorherige Beispiel C exportiert und auch C verwenden möchte, muss es auch in einer eigenen `deps` aufgeführt werden.
`javabuilder_jvm_flags`	Liste mit Strings; Standardwert ist `[]` Eingeschränkte API, nicht verwenden!
`javacopts`	Liste mit Strings; Standardwert ist `[]` Zusätzliche Compiler-Optionen für diese Bibliothek. Unterliegt der Ersetzung "Make variable" und der Bourne-Shell-Tokenisierung. Diese Compiler-Optionen werden nach den globalen Compiler-Optionen an javac übergeben.
`neverlink`	Boolescher Wert; Standardwert ist `False` Gibt an, ob diese Bibliothek nur für die Kompilierung und nicht zur Laufzeit verwendet werden soll. Dies ist hilfreich, wenn die Bibliothek während der Ausführung von der Laufzeitumgebung bereitgestellt wird. Beispiele für solche Bibliotheken sind die IDE APIs für IDE-Plug-ins oder `tools.jar` für alle Anwendungen, die auf einem Standard-JDK ausgeführt werden. Beachten Sie, dass `neverlink = 1` nicht verhindert, dass der Compiler Material aus dieser Bibliothek in Kompilierungsziele einfügt, die davon abhängig sind, wie von der Java-Sprachspezifikation zulässig (z.B. `static final`-Konstanten von `String` oder von primitiven Typen). Der bevorzugte Anwendungsfall ist daher, wenn die Laufzeitbibliothek mit der Kompilierungsbibliothek identisch ist. Wenn sich die Laufzeitbibliothek von der Kompilierungsbibliothek unterscheidet, müssen Sie dafür sorgen, dass sie sich nur an Stellen unterscheidet, an denen die JLS es nicht erlaubt, Compiler inline zuzulassen (und das für alle zukünftigen JLS-Versionen gelten muss).
`plugins`	Liste mit Labels; Standardwert ist `[]` Java-Compiler-Plug-ins, die bei der Kompilierung ausgeführt werden. Jeder in diesem Attribut angegebene `java_plugin` wird bei jeder Erstellung dieser Regel ausgeführt. Eine Bibliothek kann auch Plug-ins von Abhängigkeiten übernehmen, die `exported_plugins` verwenden. Vom Plug-in generierte Ressourcen werden in die resultierende JAR-Datei dieser Regel aufgenommen.
`proguard_specs`	Liste mit Labels; Standardwert ist `[]` Dateien, die als Proguard-Spezifikation verwendet werden sollen. Diese beschreiben die von Proguard zu verwendenden Spezifikationen. Wenn angegeben, werden sie in Abhängigkeit von dieser Bibliothek zu jedem `android_binary`-Ziel hinzugefügt. Die hier enthaltenen Dateien dürfen nur idempotente Regeln enthalten, nämlich "-dontnote", "-dontwarn", "assumenosideeffects" und Regeln, die mit "-keep" beginnen. Andere Optionen können nur in den proguard_specs von `android_binary` angezeigt werden, um eine nicht tautologische Zusammenführung zu ermöglichen.
`resource_strip_prefix`	String; der Standardwert ist `""` Das Pfadpräfix, das aus den Java-Ressourcen entfernt werden soll. Wenn angegeben, wird dieses Pfadpräfix aus jeder Datei im Attribut `resources` entfernt. Es ist ein Fehler, wenn sich eine Ressourcendatei nicht in diesem Verzeichnis befindet. Falls nicht angegeben (Standardeinstellung), wird der Pfad der Ressourcendatei gemäß derselben Logik wie das Java-Paket der Quelldateien bestimmt. Die Quelldatei unter `stuff/java/foo/bar/a.txt` befindet sich beispielsweise unter `foo/bar/a.txt`.
`runtime_deps`	Liste mit Labels; Standardwert ist `[]` Bibliotheken, die nur für die finale Binärdatei oder den Test zur Laufzeit verfügbar gemacht werden sollen. Wie die normale `deps` werden auch diese im Laufzeitklassenpfad angezeigt, jedoch im Gegensatz zu ihnen nicht im Klassenpfad der Kompilierungszeit. Hier sollten Abhängigkeiten aufgeführt sein, die nur zur Laufzeit benötigt werden. Tools zur Abhängigkeitsanalyse sollten Ziele ignorieren, die sowohl in `runtime_deps` als auch in `deps` enthalten sind.

java_lite_proto_library

Regelquelle ansehen

java_lite_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

java_lite_proto_library generiert Java-Code aus .proto-Dateien.

deps muss auf proto_library-Regeln verweisen.

Beispiel:


java_library(
    name = "lib",
    runtime_deps = [":foo"],
)

java_lite_proto_library(
    name = "foo",
    deps = [":bar"],
)

proto_library(
    name = "bar",
)

Argumente

Attribute

name

Name: erforderlich

Ein eindeutiger Name für dieses Ziel.

deps

Liste mit Labels; Standardwert ist []

Die Liste der proto_library-Regeln, für die Java-Code generiert werden soll.

java_proto_library

Regelquelle ansehen

java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

java_proto_library generiert Java-Code aus .proto-Dateien.

deps muss auf proto_library-Regeln verweisen.

Beispiel:


java_library(
    name = "lib",
    runtime_deps = [":foo_java_proto"],
)

java_proto_library(
    name = "foo_java_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

Argumente

Attribute

name

Name: erforderlich

Ein eindeutiger Name für dieses Ziel.

deps

Liste mit Labels; Standardwert ist []

Die Liste der proto_library-Regeln, für die Java-Code generiert werden soll.

java_test

Regelquelle ansehen

java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)

Eine java_test()-Regel kompiliert einen Java-Test. Ein Test ist ein binärer Wrapper um Ihren Testcode. Anstelle der zu kompilierenden Hauptklasse wird die Hauptmethode des Test-Runners aufgerufen.

Implizite Ausgabeziele

name.jar: Ein Java-Archiv.
name_deploy.jar: Ein Java-Archiv, das sich für die Bereitstellung eignet. (Wird nur bei expliziter Anforderung erstellt.) Weitere Informationen finden Sie in der Beschreibung der name_deploy.jar-Ausgabe von java_binary.

Weitere Informationen finden Sie im Abschnitt zu java_binary()-Argumenten. Diese Regel unterstützt auch alle Attribute, die allen Testregeln gemeinsam sind (*_test).

Beispiele



java_library(
    name = "tests",
    srcs = glob(["*.java"]),
    deps = [
        "//java/com/foo/base:testResources",
        "//java/com/foo/testing/util",
    ],
)

java_test(
    name = "AllTests",
    size = "small",
    runtime_deps = [
        ":tests",
        "//util/mysql",
    ],
)

Argumente

Attribute
`name`	Name: erforderlich Ein eindeutiger Name für dieses Ziel.
`deps`	Liste mit Labels; Standardwert ist `[]` Die Liste anderer Bibliotheken, die mit dem Ziel verknüpft werden sollen. Allgemeine Kommentare zu `deps` finden Sie unter Typische Attribute, die von den meisten Build-Regeln definiert werden.
`srcs`	Liste mit Labels; Standardwert ist `[]` Die Liste der Quelldateien, die zum Erstellen des Ziels verarbeitet werden. Dieses Attribut ist fast immer erforderlich, siehe Ausnahmen unten. Quelldateien vom Typ `.java` werden kompiliert. Bei generierten `.java`-Dateien ist es im Allgemeinen empfehlenswert, hier den Namen der Generierungsregel und nicht den Namen der Datei selbst anzugeben. Dies verbessert nicht nur die Lesbarkeit, sondern macht die Regel auch weniger an zukünftigen Änderungen: Wenn die Generierungsregel in Zukunft unterschiedliche Dateien generiert, müssen Sie nur eine Stelle korrigieren: die `outs` der Generierungsregel. Sie sollten die Generierungsregel nicht in `deps` auflisten, da es sich um eine Nulloperation handelt. Quelldateien vom Typ `.srcjar` werden entpackt und kompiliert. (Dies ist nützlich, wenn Sie eine Reihe von `.java`-Dateien mit einer Genrule generieren müssen.) Regeln: Wenn durch die Regel (normalerweise `genrule` oder `filegroup`) eine der oben aufgeführten Dateien generiert wird, werden diese so verwendet wie für Quelldateien beschrieben. Dieses Argument ist fast immer erforderlich, außer wenn ein `main_class`-Attribut eine Klasse im Laufzeitklassenpfad angibt oder Sie das Argument `runtime_deps` angeben.
`data`	Liste mit Labels; Standardwert ist `[]` Die Liste der Dateien, die diese Bibliothek zur Laufzeit benötigt. Allgemeine Kommentare zu `data` finden Sie unter Typische Attribute, die von den meisten Build-Regeln definiert werden.
`resources`	Liste mit Labels; Standardwert ist `[]` Eine Liste der Datendateien, die in einer Java-JAR-Datei enthalten sein sollen. Ressourcen können Quelldateien oder generierte Dateien sein. Wenn Ressourcen angegeben sind, werden sie in der JAR-Datei zusammen mit den üblichen `.class`-Dateien gebündelt, die bei der Kompilierung erstellt werden. Der Speicherort der Ressourcen in der JAR-Datei wird durch die Projektstruktur bestimmt. Bali sucht zuerst nach dem Standardverzeichnis-Layout von Maven (ein „src“-Verzeichnis gefolgt von einem Enkelzeichen des „resources“-Verzeichnisses). Wenn diese nicht gefunden wird, sucht Looker nach dem obersten Verzeichnis namens "java" oder "javatests". Wenn sich eine Ressource beispielsweise unter `<workspace root>/x/java/y/java/z` befindet, ist der Pfad der Ressource `y/java/z`. Diese Heuristik kann nicht überschrieben werden. Mit dem Attribut `resource_strip_prefix` kann jedoch ein bestimmtes alternatives Verzeichnis für Ressourcendateien angegeben werden.
`add_exports`	Liste mit Strings; Standardwert ist `[]` Dieser Bibliothek erlauben, auf die angegebene `module` oder `package` zuzugreifen. Dies entspricht den javac- und JVM --add-exports=-Flags.
`add_opens`	Liste mit Strings; Standardwert ist `[]` Erlaubt dieser Bibliothek, nachvollziehbar auf die angegebenen `module` oder `package` zuzugreifen. Dies entspricht den javac- und JVM-Flags --add-opens=.
`bootclasspath`	Label; Standardwert ist `None` Eingeschränkte API, nicht verwenden!
`classpath_resources`	Liste mit Labels; Standardwert ist `[]` VERWENDEN SIE DIESE OPTION NICHT, ES ES IST NUR, WENN DIESE NOCH NICHT MEHR DURCHFÜHRUNG IST.) Eine Liste der Ressourcen, die sich auf der Stammebene des Java-Baums befinden müssen. Der einzige Zweck dieses Attributs besteht darin, Bibliotheken von Drittanbietern zu unterstützen, für die ihre Ressourcen genau wie `"myconfig.xml"` im Klassenpfad gefunden werden müssen. Aufgrund der Gefahr von Namespace-Konflikten ist dies nur bei Binärdateien und nicht bei Bibliotheken zulässig.
`create_executable`	Boolescher Wert; Standardwert ist `True` Verworfen, verwenden Sie stattdessen `java_single_jar`.
`deploy_manifest_lines`	Liste mit Strings; Standardwert ist `[]` Eine Liste von Zeilen, die der Datei `META-INF/manifest.mf` hinzugefügt werden sollen, die für das Ziel `_deploy.jar` generiert wurde. Der Inhalt dieses Attributs unterliegt nicht* der Ersetzung „Variable machen“.
`javacopts`	Liste mit Strings; Standardwert ist `[]` Zusätzliche Compiler-Optionen für diese Binärdatei. Unterliegt der Ersetzung "Make variable" und der Bourne-Shell-Tokenisierung. Diese Compiler-Optionen werden nach den globalen Compiler-Optionen an javac übergeben.
`jvm_flags`	Liste mit Strings; Standardwert ist `[]` Eine Liste der Flags, die in das Wrapper-Skript eingebettet werden sollen, das für die Ausführung dieser Binärdatei generiert wurde. Unterliegt der Ersetzung $(location) und „Make variable“ sowie der Bourne-Shell-Tokenisierung. Das Wrapper-Skript für eine Java-Binärdatei enthält eine CLASSPATH-Definition (um alle abhängigen JAR-Dateien zu finden) und ruft den richtigen Java-Interpreter auf. Die vom Wrapper-Skript generierte Befehlszeile enthält den Namen der Hauptklasse gefolgt von einem `"$@"`, sodass Sie nach dem Klassennamen weitere Argumente übergeben können. Argumente für das Parsen durch die JVM müssen jedoch vor dem Klassennamen in der Befehlszeile angegeben werden. Der Inhalt von `jvm_flags` wird dem Wrapper-Skript hinzugefügt, bevor der Klassenname aufgeführt wird. Beachten Sie, dass dieses Attribut keine Auswirkungen auf `*_deploy.jar`-Ausgaben hat.
`launcher`	Label; Standardwert ist `None` Geben Sie ein Binärprogramm an, das zum Ausführen Ihres Java-Programms anstelle des normalen `bin/java`-Programms, das im JDK enthalten ist, verwendet wird. Das Ziel muss ein `cc_binary` sein. Jeder `cc_binary`, der die Java Invocation API implementiert, kann als Wert für dieses Attribut angegeben werden. Standardmäßig verwendet Looker den normalen JDK-Launcher (bin/java oder java.exe). Das zugehörige Bali-Flag `--java_launcher` wirkt sich nur auf die Ziele `java_binary` und `java_test` aus, für die kein `launcher`-Attribut angegeben wurde. Ihre nativen Abhängigkeiten (C++, SWIG, JNI) sind abhängig davon, ob Sie den JDK-Launcher oder einen anderen Launcher verwenden: Wenn Sie den normalen JDK Launcher (Standardeinstellung) verwenden, werden native Abhängigkeiten als gemeinsam genutzte Bibliothek mit dem Namen `{name}_nativedeps.so` erstellt. Dabei ist `{name}` das Attribut `name` dieser java_binary-Regel. Nicht verwendeter Code wird durch die Verknüpfung in dieser Konfiguration nicht entfernt. Wenn Sie einen anderen Launcher verwenden, werden native (C++) Abhängigkeiten statisch mit einer Binärdatei namens `{name}_nativedeps` verknüpft, wobei `{name}` das Attribut `name` dieser java_binary-Regel ist. In diesem Fall entfernt die Verknüpfung jeden Code, der ihrer Ansicht nach nicht verwendet wird, aus dem resultierenden Binärprogramm. Das bedeutet, dass C++-Code, auf den nur über JNI zugegriffen wird, möglicherweise nur verknüpft wird, wenn das `cc_library`-Ziel `alwayslink = 1` angibt. Wenn Sie einen anderen Launcher als den JDK-Standard-Launcher verwenden, ändert sich das Format der `*_deploy.jar`-Ausgabe. Weitere Informationen finden Sie in der java_binary-Hauptdokumentation.
`main_class`	String; der Standardwert ist `""` Name der Klasse mit der Methode `main()`, die als Einstiegspunkt verwendet werden soll. Wenn eine Regel diese Option verwendet, ist keine `srcs=[...]`-Liste erforderlich. So kann mit diesem Attribut eine ausführbare Datei aus einer Java-Bibliothek erstellt werden, die bereits eine oder mehrere `main()`-Methoden enthält. Der Wert dieses Attributs ist ein Klassenname, keine Quelldatei. Die Klasse muss zur Laufzeit verfügbar sein: Sie kann durch diese Regel (aus `srcs`) kompiliert oder durch direkte oder Transitive Abhängigkeiten (über `runtime_deps` oder `deps`) bereitgestellt werden. Wenn die Klasse nicht verfügbar ist, schlägt das Binärprogramm zur Laufzeit fehl. Es gibt keine Build-Zeitprüfung.
`neverlink`	Boolescher Wert; Standardwert ist `False`
`plugins`	Liste mit Labels; Standardwert ist `[]` Java-Compiler-Plug-ins, die bei der Kompilierung ausgeführt werden. Jeder in diesem Attribut angegebene `java_plugin` wird bei jeder Erstellung dieser Regel ausgeführt. Eine Bibliothek kann auch Plug-ins von Abhängigkeiten übernehmen, die `exported_plugins` verwenden. Vom Plug-in generierte Ressourcen werden in die resultierende JAR-Datei dieser Regel aufgenommen.
`resource_strip_prefix`	String; der Standardwert ist `""` Das Pfadpräfix, das aus den Java-Ressourcen entfernt werden soll. Wenn angegeben, wird dieses Pfadpräfix aus jeder Datei im Attribut `resources` entfernt. Es ist ein Fehler, wenn sich eine Ressourcendatei nicht in diesem Verzeichnis befindet. Falls nicht angegeben (Standardeinstellung), wird der Pfad der Ressourcendatei gemäß derselben Logik wie das Java-Paket der Quelldateien bestimmt. Die Quelldatei unter `stuff/java/foo/bar/a.txt` befindet sich beispielsweise unter `foo/bar/a.txt`.
`runtime_deps`	Liste mit Labels; Standardwert ist `[]` Bibliotheken, die nur für die finale Binärdatei oder den Test zur Laufzeit verfügbar gemacht werden sollen. Wie die normale `deps` werden auch diese im Laufzeitklassenpfad angezeigt, jedoch im Gegensatz zu ihnen nicht im Klassenpfad der Kompilierungszeit. Hier sollten Abhängigkeiten aufgeführt sein, die nur zur Laufzeit benötigt werden. Tools zur Abhängigkeitsanalyse sollten Ziele ignorieren, die sowohl in `runtime_deps` als auch in `deps` enthalten sind.
`stamp`	Ganzzahl; der Standardwert ist `0` Gibt an, ob Build-Informationen in der Binärdatei codiert werden sollen. Mögliche Werte: `stamp = 1`: Stempelt die Build-Informationen immer in die Binärdatei ab, auch in `--nostamp`-Builds. Diese Einstellung sollte vermieden werden, da sie möglicherweise das Remote-Caching für das Binärprogramm und alle davon abhängigen nachgelagerten Aktionen beendet. `stamp = 0`: Build-Informationen werden immer durch konstante Werte ersetzt. Dies ermöglicht ein gutes Caching von Build-Ergebnissen. `stamp = -1`: Das Einbetten von Build-Informationen wird durch das Flag `--[no]stamp` gesteuert. Gestempelte Binärprogramme werden nicht neu erstellt, es sei denn, ihre Abhängigkeiten ändern sich.
`test_class`	String; der Standardwert ist `""` Die Java-Klasse, die vom Test-Runner geladen werden soll. Wenn dieses Argument nicht definiert ist, werden standardmäßig der Legacy-Modus und stattdessen die Testargumente verwendet. Legen Sie das Flag `--nolegacy_bazel_java_test` so fest, dass es beim ersten Argument nicht als Fallback verwendet wird. Dieses Attribut gibt den Namen einer Java-Klasse an, die von diesem Test ausgeführt werden soll. Es ist selten erforderlich, dies festzulegen. Wird dieses Argument weggelassen, wird es aus dem `name` des Ziels und seinem relativen Quell-Root-Pfad abgeleitet. Befindet sich der Test außerhalb eines bekannten Quellstamms, gibt Bazel einen Fehler aus, wenn `test_class` nicht festgelegt ist. Bei JUnit3 muss die Testklasse entweder eine abgeleitete Klasse von `junit.framework.TestCase` sein oder eine öffentliche statische `suite()`-Methode haben, die eine `junit.framework.Test` (oder eine abgeleitete Klasse von `Test`) zurückgibt. Für JUnit4 muss die Klasse mit `org.junit.runner.RunWith` annotiert werden. Mit diesem Attribut können mehrere `java_test`-Regeln denselben `Test`-Wert (`TestCase`, `TestSuite` usw.) teilen. Normalerweise werden zusätzliche Informationen an das Attribut übergeben (z. B. über `jvm_flags=['-Dkey=value']`), damit sich sein Verhalten in jedem Fall unterscheidet, z.B. das Ausführen einer anderen Teilmenge der Tests. Dieses Attribut ermöglicht auch die Verwendung von Java-Tests außerhalb des `javatests`-Baums.
`use_launcher`	Boolescher Wert; Standardwert ist `True` Gibt an, ob das Binärprogramm einen benutzerdefinierten Launcher verwenden soll. Ist das Attribut auf „false“ gesetzt, werden das Attribut Launcher und das zugehörige Flag `--java_launcher` für dieses Ziel ignoriert.
`use_testrunner`	Boolescher Wert; Standardwert ist `True` Verwenden Sie die Klasse des Test-Runners (standardmäßig `com.google.testing.junit.runner.BazelTestRunner`) als Haupteinstiegspunkt für ein Java-Programm und geben Sie die Testklasse als Wert des Systemattributs `bazel.test_suite` an den Test-Runner an. Damit können Sie das Standardverhalten überschreiben: Die Verwendung des Test-Runners für `java_test`-Regeln und nicht für `java_binary`-Regeln. Es ist unwahrscheinlich, dass Sie dies tun wollen. Eine Verwendung ist für `AllTest`-Regeln, die von einer anderen Regel aufgerufen werden (z. B. um eine Datenbank vor dem Ausführen der Tests einzurichten). Die `AllTest`-Regel muss als `java_binary` deklariert werden, sollte jedoch weiterhin den Test-Runner als Haupteinstiegspunkt verwenden. Der Name einer Test-Runner-Klasse kann mit dem Attribut `main_class` überschrieben werden.

java_package_configuration

Regelquelle ansehen

java_package_configuration(name, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Konfiguration, die auf eine Gruppe von Paketen angewendet werden soll. Konfigurationen können zu java_toolchain.javacoptss hinzugefügt werden.

Beispiel:



java_package_configuration(
    name = "my_configuration",
    packages = [":my_packages"],
    javacopts = ["-Werror"],
)

package_group(
    name = "my_packages",
    packages = [
        "//com/my/project/...",
        "-//com/my/project/testing/...",
    ],
)

java_toolchain(
    ...,
    package_configuration = [
        ":my_configuration",
    ]
)

Argumente

Attribute
`name`	Name: erforderlich Ein eindeutiger Name für dieses Ziel.
`data`	Liste mit Labels; Standardwert ist `[]` Die Liste der Dateien, die von dieser Konfiguration zur Laufzeit benötigt werden.
`javacopts`	Liste mit Strings; Standardwert ist `[]` Java-Compiler-Flags.
`output_licenses`	Liste mit Strings; Standardwert ist `[]`
`packages`	Liste mit Labels; Standardwert ist `[]` Die Gruppe von `package_group`s, auf die die Konfiguration angewendet werden soll.

java_plugin

Regelquelle ansehen

java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

java_plugin definiert Plug-ins für den Java-Compiler, der von außerhalb ausgeführt wird. Derzeit werden nur Annotationsprozessoren unterstützt. Eine java_library- oder java_binary-Regel kann Plug-ins ausführen, indem sie über das Attribut plugins von ihnen abhängig ist. Ein java_library kann Plug-ins mithilfe von exported_plugins auch automatisch in direkt davon abhängige Bibliotheken exportieren.

Implizite Ausgabeziele

libname.jar: Ein Java-Archiv.

Argumente sind mit java_library bis auf das Hinzufügen des Arguments processor_class identisch.

Argumente

Attribute
`name`	Name: erforderlich Ein eindeutiger Name für dieses Ziel.
`deps`	Liste mit Labels; Standardwert ist `[]` Die Liste der Bibliotheken, die mit dieser Bibliothek verknüpft werden sollen. Allgemeine Kommentare zu `deps` finden Sie unter Typische Attribute, die von den meisten Build-Regeln definiert werden. Die JAR-Dateien, die von den in `deps` aufgeführten `java_library`-Regeln erstellt wurden, befinden sich im Klassenpfad zur Kompilierungszeit dieser Regel. Außerdem erfolgt das vorübergehende Schließen ihrer `deps`, `runtime_deps` und `exports` auf dem Laufzeitklassenpfad. Im Gegensatz dazu sind Ziele im Attribut `data` in den Runfiles enthalten, aber weder im Klassenpfad für die Kompilierungszeit noch im Laufzeitklassenpfad.
`srcs`	Liste mit Labels; Standardwert ist `[]` Die Liste der Quelldateien, die zum Erstellen des Ziels verarbeitet werden. Dieses Attribut ist fast immer erforderlich, siehe Ausnahmen unten. Quelldateien vom Typ `.java` werden kompiliert. Bei generierten `.java`-Dateien ist es im Allgemeinen empfehlenswert, hier den Namen der Generierungsregel und nicht den Namen der Datei selbst anzugeben. Dies verbessert nicht nur die Lesbarkeit, sondern macht die Regel auch weniger an zukünftigen Änderungen: Wenn die Generierungsregel in Zukunft unterschiedliche Dateien generiert, müssen Sie nur eine Stelle korrigieren: die `outs` der Generierungsregel. Sie sollten die Generierungsregel nicht in `deps` auflisten, da es sich um eine Nulloperation handelt. Quelldateien vom Typ `.srcjar` werden entpackt und kompiliert. (Dies ist nützlich, wenn Sie eine Reihe von `.java`-Dateien mit einer Genrule generieren müssen.) Regeln: Wenn durch die Regel (normalerweise `genrule` oder `filegroup`) eine der oben aufgeführten Dateien generiert wird, werden diese so verwendet wie für Quelldateien beschrieben. Quelldateien vom Typ `.properties` werden als Ressourcen behandelt. Alle anderen Dateien werden ignoriert, solange mindestens eine Datei des oben beschriebenen Dateityps vorhanden ist. Andernfalls wird ein Fehler ausgegeben. Dieses Argument ist fast immer erforderlich, es sei denn, Sie geben das Argument `runtime_deps` an.
`data`	Liste mit Labels; Standardwert ist `[]` Die Liste der Dateien, die diese Bibliothek zur Laufzeit benötigt. Allgemeine Kommentare zu `data` finden Sie unter Typische Attribute, die von den meisten Build-Regeln definiert werden. Beim Erstellen einer `java_library` legt Looker diese Dateien nirgendwo hin. Wenn die `data`-Dateien generiert sind, werden sie von Qwiklabs generiert. Beim Erstellen eines Tests, der von dieser `java_library` abhängig ist, kopiert oder verknüpft Qwiklabs die `data`-Dateien in den Runfiles-Bereich.
`resources`	Liste mit Labels; Standardwert ist `[]` Eine Liste der Datendateien, die in einer Java-JAR-Datei enthalten sein sollen. Ressourcen können Quelldateien oder generierte Dateien sein. Wenn Ressourcen angegeben sind, werden sie in der JAR-Datei zusammen mit den üblichen `.class`-Dateien gebündelt, die bei der Kompilierung erstellt werden. Der Speicherort der Ressourcen in der JAR-Datei wird durch die Projektstruktur bestimmt. Bali sucht zuerst nach dem Standardverzeichnis-Layout von Maven (ein „src“-Verzeichnis gefolgt von einem Enkelzeichen des „resources“-Verzeichnisses). Wenn diese nicht gefunden wird, sucht Looker nach dem obersten Verzeichnis namens "java" oder "javatests". Wenn sich eine Ressource beispielsweise unter `<workspace root>/x/java/y/java/z` befindet, ist der Pfad der Ressource `y/java/z`. Diese Heuristik kann nicht überschrieben werden. Mit dem Attribut `resource_strip_prefix` kann jedoch ein bestimmtes alternatives Verzeichnis für Ressourcendateien angegeben werden.
`add_exports`	Liste mit Strings; Standardwert ist `[]` Dieser Bibliothek erlauben, auf die angegebene `module` oder `package` zuzugreifen. Dies entspricht den javac- und JVM --add-exports=-Flags.
`add_opens`	Liste mit Strings; Standardwert ist `[]` Erlaubt dieser Bibliothek, nachvollziehbar auf die angegebenen `module` oder `package` zuzugreifen. Dies entspricht den javac- und JVM-Flags --add-opens=.
`bootclasspath`	Label; Standardwert ist `None` Eingeschränkte API, nicht verwenden!
`generates_api`	Boolescher Wert; Standardwert ist `False` Dieses Attribut kennzeichnet Annotationsprozessoren, die API-Code generieren. Wenn eine Regel einen API-generierenden Annotationsprozessor verwendet, können andere davon abhängige Regeln nur dann auf den generierten Code verweisen, wenn ihre Kompilierungsaktionen nach der Generierungsregel geplant sind. Dieses Attribut weist Looker an, Planungseinschränkungen einzuführen, wenn „--java_header_compilation“ aktiviert ist. WARNUNG: Dieses Attribut wirkt sich auf die Build-Leistung aus. Verwenden Sie es nur, wenn es erforderlich ist.
`javabuilder_jvm_flags`	Liste mit Strings; Standardwert ist `[]` Eingeschränkte API, nicht verwenden!
`javacopts`	Liste mit Strings; Standardwert ist `[]` Zusätzliche Compiler-Optionen für diese Bibliothek. Unterliegt der Ersetzung "Make variable" und der Bourne-Shell-Tokenisierung. Diese Compiler-Optionen werden nach den globalen Compiler-Optionen an javac übergeben.
`neverlink`	Boolescher Wert; Standardwert ist `False` Gibt an, ob diese Bibliothek nur für die Kompilierung und nicht zur Laufzeit verwendet werden soll. Dies ist hilfreich, wenn die Bibliothek während der Ausführung von der Laufzeitumgebung bereitgestellt wird. Beispiele für solche Bibliotheken sind die IDE APIs für IDE-Plug-ins oder `tools.jar` für alle Anwendungen, die auf einem Standard-JDK ausgeführt werden. Beachten Sie, dass `neverlink = 1` nicht verhindert, dass der Compiler Material aus dieser Bibliothek in Kompilierungsziele einfügt, die davon abhängig sind, wie von der Java-Sprachspezifikation zulässig (z.B. `static final`-Konstanten von `String` oder von primitiven Typen). Der bevorzugte Anwendungsfall ist daher, wenn die Laufzeitbibliothek mit der Kompilierungsbibliothek identisch ist. Wenn sich die Laufzeitbibliothek von der Kompilierungsbibliothek unterscheidet, müssen Sie dafür sorgen, dass sie sich nur an Stellen unterscheidet, an denen die JLS es nicht erlaubt, Compiler inline zuzulassen (und das für alle zukünftigen JLS-Versionen gelten muss).
`output_licenses`	Liste mit Strings; Standardwert ist `[]`
`plugins`	Liste mit Labels; Standardwert ist `[]` Java-Compiler-Plug-ins, die bei der Kompilierung ausgeführt werden. Jeder in diesem Attribut angegebene `java_plugin` wird bei jeder Erstellung dieser Regel ausgeführt. Eine Bibliothek kann auch Plug-ins von Abhängigkeiten übernehmen, die `exported_plugins` verwenden. Vom Plug-in generierte Ressourcen werden in die resultierende JAR-Datei dieser Regel aufgenommen.
`processor_class`	String; der Standardwert ist `""` Die Prozessorklasse ist der voll qualifizierte Typ der Klasse, den der Java-Compiler als Einstiegspunkt für den Annotationsprozessor verwenden soll. Wenn keine Angabe erfolgt, trägt diese Regel keinen Annotationsprozessor zur Annotationsverarbeitung des Java-Compilers bei. Sein Laufzeitklassenpfad ist jedoch weiterhin im Annotationsprozessorpfad des Compilers enthalten. Diese ist in erster Linie für die Verwendung von fehleranfälligen Plug-ins vorgesehen, die mit java.util.ServiceLoader aus dem Pfad des Annotationsprozessors geladen werden.
`proguard_specs`	Liste mit Labels; Standardwert ist `[]` Dateien, die als Proguard-Spezifikation verwendet werden sollen. Diese beschreiben die von Proguard zu verwendenden Spezifikationen. Wenn angegeben, werden sie in Abhängigkeit von dieser Bibliothek zu jedem `android_binary`-Ziel hinzugefügt. Die hier enthaltenen Dateien dürfen nur idempotente Regeln enthalten, nämlich "-dontnote", "-dontwarn", "assumenosideeffects" und Regeln, die mit "-keep" beginnen. Andere Optionen können nur in den proguard_specs von `android_binary` angezeigt werden, um eine nicht tautologische Zusammenführung zu ermöglichen.
`resource_strip_prefix`	String; der Standardwert ist `""` Das Pfadpräfix, das aus den Java-Ressourcen entfernt werden soll. Wenn angegeben, wird dieses Pfadpräfix aus jeder Datei im Attribut `resources` entfernt. Es ist ein Fehler, wenn sich eine Ressourcendatei nicht in diesem Verzeichnis befindet. Falls nicht angegeben (Standardeinstellung), wird der Pfad der Ressourcendatei gemäß derselben Logik wie das Java-Paket der Quelldateien bestimmt. Die Quelldatei unter `stuff/java/foo/bar/a.txt` befindet sich beispielsweise unter `foo/bar/a.txt`.

java_runtime

Regelquelle ansehen

java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)

Gibt die Konfiguration für eine Java-Laufzeit an.

Beispiel:



java_runtime(
    name = "jdk-9-ea+153",
    srcs = glob(["jdk9-ea+153/**"]),
    java_home = "jdk9-ea+153",
)

Argumente

Attribute
`name`	Name: erforderlich Ein eindeutiger Name für dieses Ziel.
`srcs`	Liste mit Labels; Standardwert ist `[]` Alle Dateien in der Laufzeit.
`default_cds`	Label; Standardwert ist `None` Standard-CDS-Archiv für die hermetische `java_runtime`. Wenn die Hermetik für ein `java_binary`-Ziel aktiviert ist und das Ziel durch Angabe des Attributs `classlist` kein eigenes CDS-Archiv bereitstellt, wird die `java_runtime`-Standard-CDS in der JAR-Datei für die hermetische Bereitstellung gepackt.
`hermetic_srcs`	Liste mit Labels; Standardwert ist `[]` Dateien in der Laufzeit, die für hermetische Bereitstellungen benötigt werden.
`hermetic_static_libs`	Liste mit Labels; Standardwert ist `[]` Die Bibliotheken, die für hermetische Bereitstellungen statisch mit dem Launcher verknüpft sind
`java`	Label; Standardwert ist `None` Der Pfad zur ausführbaren Java-Datei.
`java_home`	String; der Standardwert ist `""` Der Pfad zum Stammverzeichnis der Laufzeit. Unterliegt dem Ersatz für die Variable „Make“. Wenn dieser Pfad absolut ist, gibt die Regel eine nicht hermetische Java-Laufzeit mit einem bekannten Pfad an. In diesem Fall müssen die Attribute `srcs` und `java` leer sein.
`lib_ct_sym`	Label; Standardwert ist `None` Die für die Kompilierung mit `--release` erforderliche Datei lib/ct.sym. Wenn keine Angabe erfolgt und sich in `srcs` genau eine Datei befindet, deren Pfad mit `/lib/ct.sym` endet, wird diese Datei verwendet.
`lib_modules`	Label; Standardwert ist `None` Die für hermetische Bereitstellungen benötigte lib/modules-Datei.
`output_licenses`	Liste mit Strings; Standardwert ist `[]`
`version`	Ganzzahl; der Standardwert ist `0` Die Funktionsversion der Java-Laufzeit. Das heißt, die von `Runtime.version().feature()` zurückgegebene Ganzzahl.

java_toolchain

Regelquelle ansehen

java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)

Gibt die Konfiguration für den Java-Compiler an. Welche Toolchain verwendet werden soll, kann mit dem Argument "--java_warning" geändert werden. Normalerweise sollten Sie diese Art von Regeln nur schreiben, wenn Sie Ihren Java-Compiler optimieren möchten.

Beispiele

Ein einfaches Beispiel wäre:



java_toolchain(
    name = "toolchain",
    source_version = "7",
    target_version = "7",
    bootclasspath = ["//tools/jdk:bootclasspath"],
    xlint = [ "classfile", "divzero", "empty", "options", "path" ],
    javacopts = [ "-g" ],
    javabuilder = ":JavaBuilder_deploy.jar",
)

Argumente

Attribute
`name`	Name: erforderlich Ein eindeutiger Name für dieses Ziel.
`android_lint_data`	Liste mit Labels; Standardwert ist `[]` Labels der Tools, die für die Labelerweiterung in android_lint_jvm_opts verfügbar sind.
`android_lint_jvm_opts`	Liste mit Strings; Standardwert ist `[]` Die Liste der Argumente für die JVM beim Aufrufen von Android Lint.
`android_lint_opts`	Liste mit Strings; Standardwert ist `[]` Die Liste der Android Lint-Argumente.
`android_lint_package_configuration`	Liste mit Labels; Standardwert ist `[]` Android Lint-Konfiguration, die auf die angegebenen Paketgruppen angewendet werden soll.
`android_lint_runner`	Label; Standardwert ist `None` Label des Android Lint-Runners, falls vorhanden.
`bootclasspath`	Liste mit Labels; Standardwert ist `[]` Die Bootclasspath-Einträge für das Java-Ziel Entspricht dem Flag -bootclasspath von javac.
`compatible_javacopts`	null; default is `{}` Interne API, nicht verwenden!
`deps_checker`	Label; Standardwert ist `None` Label der JAR-Datei für die ImportDepsChecker-Bereitstellung.
`forcibly_disable_header_compilation`	Boolescher Wert; Standardwert ist `False` Überschreibt „--java_header_compilation“, um die Headerkompilierung auf Plattformen zu deaktivieren, die sie nicht unterstützen, z.B. JDK 7 Balkal.
`genclass`	Label; Standardwert ist `None` Label der Bereitstellungs-JAR-Datei für GenClass.
`header_compiler`	Label; Standardwert ist `None` Label des Header-Compilers. Erforderlich, wenn --java_header_compilation aktiviert ist.
`header_compiler_builtin_processors`	Liste mit Strings; Standardwert ist `[]` Interne API, nicht verwenden!
`header_compiler_direct`	Label; Standardwert ist `None` Optionales Label des Header-Compilers, der für direkte Klassenpfadaktionen ohne API-generierende Annotationsprozessoren verwendet werden soll. Die Verarbeitung von Anmerkungen wird von diesem Tool nicht unterstützt.
`ijar`	Label; Standardwert ist `None` Label der ausführbaren Ijar-Datei.
`jacocorunner`	Label; Standardwert ist `None` Label der Bereitstellungs-JacococoverRunner-JAR-Datei.
`java_runtime`	Label; Standardwert ist `None` Die java_runtime, die mit dieser Toolchain verwendet werden soll. In der Ausführungskonfiguration ist der Standardwert „java_runtime“.
`javabuilder`	Label; Standardwert ist `None` Label der JavaBuilder-Bereitstellungs-JAR-Datei.
`javabuilder_data`	Liste mit Labels; Standardwert ist `[]` Labels von Daten, die für die Labelerweiterung in javabuilder_jvm_opts verfügbar sind.
`javabuilder_jvm_opts`	Liste mit Strings; Standardwert ist `[]` Die Liste der Argumente für die JVM beim Aufrufen von JavaBuilder.
`javac_supports_multiplex_workers`	Boolescher Wert; Standardwert ist `True` „True“, wenn JavaBuilder die Ausführung als persistenter Multiplex-Worker unterstützt, und „false“, wenn dies nicht der Fall ist.
`javac_supports_worker_cancellation`	Boolescher Wert; Standardwert ist `True` "True", wenn JavaBuilder das Beenden persistenter Worker unterstützt, "false", wenn dies nicht der Fall ist.
`javac_supports_worker_multiplex_sandboxing`	Boolescher Wert; Standardwert ist `False` "True", wenn JavaBuilder die Ausführung als persistenter Multiplex-Worker mit Sandbox-Technologie unterstützt, und "false", wenn dies nicht der Fall ist.
`javac_supports_workers`	Boolescher Wert; Standardwert ist `True` "True", wenn JavaBuilder die Ausführung als persistente Worker unterstützt, "false", wenn dies nicht der Fall ist.
`javacopts`	Liste mit Strings; Standardwert ist `[]` Die Liste der zusätzlichen Argumente für den Java-Compiler. Eine umfassende Liste möglicher Java-Compiler-Flags finden Sie in der Dokumentation des Java-Compilers.
`jspecify_implicit_deps`	Label; Standardwert ist `None` Experimentell, nicht verwenden!
`jspecify_javacopts`	Liste mit Strings; Standardwert ist `[]` Experimentell, nicht verwenden!
`jspecify_packages`	Liste mit Labels; Standardwert ist `[]` Experimentell, nicht verwenden!
`jspecify_processor`	Label; Standardwert ist `None` Experimentell, nicht verwenden!
`jspecify_processor_class`	String; der Standardwert ist `""` Experimentell, nicht verwenden!
`jspecify_stubs`	Liste mit Labels; Standardwert ist `[]` Experimentell, nicht verwenden!
`jvm_opts`	Liste mit Strings; Standardwert ist `[]` Die Liste der Argumente für die JVM beim Aufrufen des Java-Compilers. In der Dokumentation zu Java-VMs finden Sie eine umfassende Liste möglicher Flags für diese Option.
`misc`	Liste mit Strings; Standardwert ist `[]` Eingestellt: Verwenden Sie stattdessen javacopts
`oneversion`	Label; Standardwert ist `None` Label der Binärdatei für die Erzwingung einer Version.
`oneversion_allowlist_for_tests`	Label; Standardwert ist `None` Label der Zulassungsliste für eine Version für Tests.
`oneversion_whitelist`	Label; Standardwert ist `None` Label der Zulassungsliste für eine Version.
`package_configuration`	Liste mit Labels; Standardwert ist `[]` Konfiguration, die auf die angegebenen Paketgruppen angewendet werden soll.
`proguard_allowlister`	Label; Standardwert ist `"@bazel_tools//tools/jdk:proguard_whitelister"` Label der Proguard-Zulassungsliste.
`reduced_classpath_incompatible_processors`	Liste mit Strings; Standardwert ist `[]` Interne API, nicht verwenden!
`singlejar`	Label; Standardwert ist `None` Label der SingleJar-Bereitstellungs-JAR-Datei.
`source_version`	String; der Standardwert ist `""` Die Java-Quellversion (z.B. „6“ oder „7“). Sie gibt an, welche Codestrukturen im Java-Quellcode zulässig sind.
`target_version`	String; der Standardwert ist `""` Die Java-Zielversion (z.B. „6“ oder „7“). Damit wird angegeben, für welche Java-Laufzeit die Klasse erstellt werden soll.
`timezone_data`	Label; Standardwert ist `None` Label einer Ressourcen-JAR-Datei, die Zeitzonendaten enthält. Wenn festgelegt, werden die Zeitzonendaten als implizite Laufzeitabhängigkeit aller java_binary-Regeln hinzugefügt.
`tools`	Liste mit Labels; Standardwert ist `[]` Labels von Tools, die für die Labelerweiterung in jvm_opts verfügbar sind.
`turbine_data`	Liste mit Labels; Standardwert ist `[]` Labels mit Daten, die für die Labelerweiterung in turbine_jvm_opts verfügbar sind.
`turbine_jvm_opts`	Liste mit Strings; Standardwert ist `[]` Die Liste der Argumente für die JVM beim Aufrufen von Turbine.
`xlint`	Liste mit Strings; Standardwert ist `[]` Die Liste mit Warnungen, die der Standardliste hinzugefügt oder daraus entfernt werden sollen. Sie wird mit einem Bindestrich entfernt. Weitere Informationen finden Sie in der Javac-Dokumentation zu den Xlint-Optionen.