BazelCon 2025 का शेड्यूल लाइव है. अभी रजिस्टर करें!

इस पेज का अनुवाद Cloud Translation API से किया गया है.

Java के नियम

एक रात का किराया · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

नियम

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

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)

यह Java संग्रह ("jar फ़ाइल") बनाता है. साथ ही, नियम के नाम वाली रैपर शेल स्क्रिप्ट भी बनाता है. रैपर शेल स्क्रिप्ट, क्लासपाथ का इस्तेमाल करती है. इसमें अन्य चीज़ों के साथ-साथ, हर उस लाइब्रेरी के लिए जार फ़ाइल शामिल होती है जिस पर बाइनरी निर्भर करती है. रैपर शेल स्क्रिप्ट चलाते समय, खाली नहीं है JAVABIN एनवायरमेंट वैरिएबल को Bazel के --java_runtime_version फ़्लैग के ज़रिए तय किए गए वर्शन के मुकाबले प्राथमिकता दी जाएगी.

रैपर स्क्रिप्ट, कई यूनीक फ़्लैग स्वीकार करती है. रैपर के साथ काम करने वाले कॉन्फ़िगर किए जा सकने वाले फ़्लैग और एनवायरमेंट वैरिएबल की सूची देखने के लिए, //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt पर जाएं.

इंप्लिसिट आउटपुट टारगेट

name.jar: यह एक Java संग्रह है. इसमें क्लास फ़ाइलें और अन्य संसाधन होते हैं. ये संसाधन, बाइनरी की सीधी डिपेंडेंसी से जुड़े होते हैं.
name-src.jar: यह एक ऐसा संग्रह है जिसमें सोर्स ("सोर्स जार") शामिल होते हैं.
name_deploy.jar: डिप्लॉयमेंट के लिए सही Java संग्रह (सिर्फ़ तब बनाया जाता है, जब इसके लिए साफ़ तौर पर अनुरोध किया गया हो).
अपने नियम के लिए <name>_deploy.jar टारगेट बनाने से, मेनिफ़ेस्ट वाली एक जार फ़ाइल बनती है. इससे java -jar कमांड या रैपर स्क्रिप्ट के --singlejar विकल्प का इस्तेमाल करके, फ़ाइल को चलाया जा सकता है. java -jar के बजाय रैपर स्क्रिप्ट का इस्तेमाल करना बेहतर होता है, क्योंकि यह JVM फ़्लैग और नेटिव लाइब्रेरी लोड करने के विकल्प भी पास करती है.

डिप्लॉय जार में वे सभी क्लास शामिल होती हैं जिन्हें क्लासलोडर ढूंढ सकता है. यह क्लासलोडर, बाइनरी की रैपर स्क्रिप्ट में क्लासपाथ को शुरू से आखिर तक खोजता है. इसमें डिपेंडेंसी के लिए ज़रूरी नेटिव लाइब्रेरी भी शामिल होती हैं. ये रनटाइम के दौरान JVM में अपने-आप लोड हो जाते हैं.

अगर आपके टारगेट में launcher एट्रिब्यूट के बारे में बताया गया है, तो _deploy.jar फ़ाइल सामान्य JAR फ़ाइल के बजाय, नेटिव बाइनरी होगी. इसमें लॉन्चर के साथ-साथ, आपके नियम की सभी नेटिव (C++) डिपेंडेंसी शामिल होंगी. इन सभी को एक स्टैटिक बाइनरी में लिंक किया जाएगा. असल जार फ़ाइल के बाइट, उस नेटिव बाइनरी में जोड़ दिए जाएंगे. इससे एक बाइनरी ब्लोब बन जाएगा, जिसमें एक्ज़ीक्यूटेबल और Java कोड, दोनों शामिल होंगे. नतीजे के तौर पर मिली JAR फ़ाइल को सीधे तौर पर चलाया जा सकता है. इसे किसी नेटिव बाइनरी की तरह चलाया जाता है.
name_deploy-src.jar: यह एक ऐसा संग्रह होता है जिसमें टारगेट के ट्रांज़िटिव क्लोज़र से इकट्ठा किए गए सोर्स शामिल होते हैं. ये deploy.jar में मौजूद क्लास से मेल खाएंगे. हालांकि, ऐसा सिर्फ़ तब होगा, जब जार का कोई मेल खाने वाला सोर्स जार न हो.

srcs के बिना, java_binary नियम में deps एट्रिब्यूट का इस्तेमाल नहीं किया जा सकता. ऐसे नियम के लिए, runtime_deps से मिले main_class की ज़रूरत होती है.

यहां दिए गए कोड स्निपेट में, एक सामान्य गड़बड़ी के बारे में बताया गया है:

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

इसके बजाय, यह तरीका अपनाएं:

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

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम. ऐप्लिकेशन के मुख्य एंट्री पॉइंट वाली सोर्स फ़ाइल के नाम का इस्तेमाल करना एक अच्छा तरीका है. हालांकि, इसमें एक्सटेंशन शामिल नहीं होना चाहिए. उदाहरण के लिए, अगर आपके एंट्री पॉइंट का नाम `Main.java` है, तो आपका नाम `Main` हो सकता है.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखें. ये टिप्पणियां, ज़्यादातर बिल्ड नियमों के तहत तय किए गए सामान्य एट्रिब्यूट में दी गई हैं.
`srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. यह एट्रिब्यूट लगभग हमेशा ज़रूरी होता है. हालांकि, कुछ मामलों में इसकी ज़रूरत नहीं होती. इनके बारे में यहां बताया गया है. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के मामले में, आम तौर पर यह सलाह दी जाती है कि फ़ाइल के नाम के बजाय, यहां फ़ाइल जनरेट करने वाले नियम का नाम डालें. इससे न सिर्फ़ पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम, आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह बदलाव करना होगा: जनरेट करने वाले नियम का `outs`. आपको जनरेट करने के नियम को `deps` में शामिल नहीं करना चाहिए, क्योंकि यह नो-ऑप है. `.srcjar` टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उनका इस्तेमाल उसी तरह किया जाएगा जैसा सोर्स फ़ाइलों के लिए बताया गया है. यह तर्क लगभग हमेशा ज़रूरी होता है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर कोई क्लास तय करता है या आपने `runtime_deps` तर्क तय किया है, तो यह तर्क ज़रूरी नहीं होता.
`resources`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधन तय किए गए हैं, तो उन्हें जार में बंडल किया जाएगा. साथ ही, कंपाइल करने से बनी सामान्य `.class` फ़ाइलें भी शामिल की जाएंगी. jar फ़ाइल में मौजूद रिसॉर्स की जगह, प्रोजेक्ट स्ट्रक्चर से तय होती है. Bazel, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को देखता है. इसमें "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री का ग्रैंडचाइल्ड होता है. अगर ऐसा नहीं होता है, तो Bazel सबसे ऊपर मौजूद "java" या "javatests" नाम की डायरेक्ट्री खोजता है. इसलिए, उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमानित तरीके को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरा डायरेक्ट्री तय किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
`classpath_resources`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई और तरीका न हो) उन संसाधनों की सूची जो Java ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का मकसद सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना है जिनके संसाधनों को क्लासपाथ पर के तौर पर ढूंढना ज़रूरी है.`"myconfig.xml"` नेमस्पेस के टकराव के खतरे की वजह से, इसे सिर्फ़ बाइनरी पर इस्तेमाल किया जा सकता है, लाइब्रेरी पर नहीं.
`create_executable`	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से `True` होता है इस सुविधा के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय, `java_single_jar` का इस्तेमाल करें.
`deploy_env`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है अन्य `java_binary` टारगेट की सूची. ये टारगेट, इस बाइनरी के लिए डिप्लॉयमेंट एनवायरमेंट को दिखाते हैं. इस एट्रिब्यूट को तब सेट करें, जब आपको ऐसा प्लगिन बनाना हो जिसे किसी दूसरे `java_binary` से लोड किया जाएगा. इस एट्रिब्यूट को सेट करने से, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉय जार) से सभी डिपेंडेंसी बाहर निकल जाती हैं. ये डिपेंडेंसी, इस बाइनरी और `deploy_env` में बताए गए टारगेट के बीच शेयर की जाती हैं.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है `META-INF/manifest.mf` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची.`_deploy.jar` इस एट्रिब्यूट के कॉन्टेंट को "बदलाव की अनुमति दें" सेटिंग के तहत बदला नहीं जा सकता*.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. कंपाइलर के इन विकल्पों को, ग्लोबल कंपाइलर के विकल्पों के बाद javac को पास किया जाता है.
`jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह $(location) और "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है. साथ ही, यह बोर्न शेल टोकनाइज़ेशन पर भी निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH की परिभाषा शामिल होती है. इससे सभी डिपेंडेंट जार फ़ाइलें मिलती हैं. साथ ही, यह सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम शामिल होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के ज़रिए पार्स किए जाने वाले आर्ग्युमेंट को कमांड लाइन पर क्लासनेम से पहले तय किया जाना चाहिए. `jvm_flags` का कॉन्टेंट, रैपर स्क्रिप्ट में क्लासनेम से पहले जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`launcher`	लेबल; डिफ़ॉल्ट वैल्यू `None` है JDK में शामिल सामान्य `bin/java` प्रोग्राम के बजाय, अपने Java प्रोग्राम को चलाने के लिए किसी बाइनरी को तय करें. टारगेट `cc_binary` होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, `cc_binary` को सेट किया जा सकता है. `cc_binary`, Java Invocation API को लागू करता हो. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़ा `--java_launcher` Bazel फ़्लैग, सिर्फ़ उन `java_binary` और `java_test` टारगेट पर असर डालता है जिनमें `launcher` एट्रिब्यूट नहीं बताया गया है. ध्यान दें कि आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी. यह इस बात पर निर्भर करता है कि JDK लॉन्चर का इस्तेमाल किया जा रहा है या किसी अन्य लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां `{name}_nativedeps.so`, इस java_binary नियम का `name` एट्रिब्यूट है.`{name}` इस कॉन्फ़िगरेशन में, लिंक करने वाला व्यक्ति ऐसे कोड को नहीं हटाता है जिसका इस्तेमाल नहीं किया गया है. अगर किसी अन्य लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी को `{name}_nativedeps` नाम के बाइनरी में स्टैटिक तौर पर लिंक किया जाता है. यहां `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस मामले में, लिंक करने वाला प्रोग्राम, नतीजे के तौर पर मिले बाइनरी से ऐसे कोड को हटा देगा जिसका इस्तेमाल नहीं किया गया है. इसका मतलब है कि सिर्फ़ JNI के ज़रिए ऐक्सेस किए गए किसी भी C++ कोड को तब तक लिंक नहीं किया जा सकता, जब तक कि वह `cc_library` टारगेट `alwayslink = 1` के बारे में न बताता हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी अन्य लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, `main()` तरीके वाली क्लास का नाम. अगर किसी नियम में इस विकल्प का इस्तेमाल किया जाता है, तो उसे `srcs=[...]` सूची की ज़रूरत नहीं होती. इसलिए, इस एट्रिब्यूट की मदद से, Java लाइब्रेरी से एक एक्ज़ीक्यूटेबल बनाया जा सकता है. इसमें पहले से ही एक या उससे ज़्यादा `main()` तरीके शामिल होते हैं. इस एट्रिब्यूट की वैल्यू, क्लास का नाम है, न कि सोर्स फ़ाइल. क्लास, रनटाइम पर उपलब्ध होनी चाहिए: इसे इस नियम के तहत कंपाइल किया जा सकता है (`srcs` से) या इसे डायरेक्ट या ट्रांज़िटिव डिपेंडेंसी (`runtime_deps` या `deps` के ज़रिए) से उपलब्ध कराया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो बाइनरी, रनटाइम पर काम नहीं करेगी. बिल्ड-टाइम की कोई जांच नहीं होती.
`plugins`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है कंपाइल-टाइम पर चलाने के लिए, Java कंपाइलर प्लगिन. इस एट्रिब्यूट में बताए गए हर `java_plugin` को तब चलाया जाएगा, जब यह नियम बनाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से भी प्लगिन मिल सकते हैं जो `exported_plugins` का इस्तेमाल करती हैं. इस नियम के नतीजे के तौर पर मिले जार में, प्लगिन से जनरेट किए गए संसाधन शामिल होंगे.
`resource_jars`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है अब इस्तेमाल नहीं किया जा सकता: इसके बजाय, java_import और deps या runtime_deps का इस्तेमाल करें.
`resource_strip_prefix`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है Java रिसॉर्स से पाथ प्रीफ़िक्स हटाने का विकल्प. अगर इस विकल्प को चुना जाता है, तो `resources` एट्रिब्यूट में मौजूद हर फ़ाइल से पाथ प्रीफ़िक्स हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर इसे तय नहीं किया जाता है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल, `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है लाइब्रेरी को सिर्फ़ फ़ाइनल बाइनरी या रनटाइम पर टेस्ट के लिए उपलब्ध कराया जा सकता है. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, उनसे अलग, ये कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी का विश्लेषण करने वाले टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `-1` है बिल्ड की जानकारी को बाइनरी में कोड में बदला जाए या नहीं. इन वैल्यू का इस्तेमाल किया जा सकता है: `stamp = 1`: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. भले ही, `--nostamp` बिल्ड में ऐसा न किया गया हो. इस सेटिंग का इस्तेमाल नहीं करना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर डाउनस्ट्रीम कार्रवाइयों के लिए रिमोट कैशिंग बंद हो जाती है. `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजों को बेहतर तरीके से कैश मेमोरी में सेव किया जा सकता है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की सुविधा, `--[no]stamp` फ़्लैग से कंट्रोल की जाती है. स्टैंप किए गए बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`use_launcher`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है क्या बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए launcher एट्रिब्यूट और इससे जुड़ा `--java_launcher` फ़्लैग अनदेखा कर दिया जाएगा.
`use_testrunner`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है Java प्रोग्राम के लिए, टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करें. साथ ही, टेस्ट क्लास को टेस्ट रनर को `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर उपलब्ध कराएं. इसका इस्तेमाल, डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. डिफ़ॉल्ट व्यवहार यह है कि `java_test` नियमों के लिए टेस्ट रनर का इस्तेमाल किया जाता है और `java_binary` नियमों के लिए इसका इस्तेमाल नहीं किया जाता. ऐसा हो सकता है कि आपको यह तरीका न अपनाना पड़े. इसका इस्तेमाल, `AllTest` ऐसे नियमों के लिए किया जाता है जिन्हें किसी दूसरे नियम से लागू किया जाता है. उदाहरण के लिए, जांच शुरू करने से पहले डेटाबेस सेट अप करने के लिए. `AllTest` नियम को `java_binary` के तौर पर घोषित किया जाना चाहिए. हालांकि, इसे अब भी टेस्ट रनर का इस्तेमाल मुख्य एंट्री पॉइंट के तौर पर करना चाहिए. टेस्ट रनर क्लास के नाम को `main_class` एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है.

java_import

नियम का सोर्स देखें

java_import(name, deps, data, 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, visibility)

इस नियम के तहत, पहले से कंपाइल की गई .jar फ़ाइलों को java_library और java_binary नियमों के लिए लाइब्रेरी के तौर पर इस्तेमाल किया जा सकता है.

उदाहरण

    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",
        ],
    )

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. java_library.deps देखें.
`constraints`	स्ट्रिंग की सूची; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट वैल्यू `[]` है Java लाइब्रेरी के तौर पर इस नियम पर लगाई गई अतिरिक्त सीमाएं.
`exports`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस नियम के उपयोगकर्ताओं के लिए उपलब्ध कराने के लिए टारगेट. java_library.exports देखें.
`jars`	लेबल की सूची; ज़रूरी है इस टारगेट पर निर्भर करने वाले Java टारगेट को दी गई JAR फ़ाइलों की सूची.
`neverlink`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइल करने के लिए करें, न कि रनटाइम के दौरान. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट, एक्ज़ीक्यूशन के दौरान उपलब्ध कराता है. इस तरह की लाइब्रेरी के उदाहरण हैं: आईडीई प्लग-इन के लिए आईडीई एपीआई या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए `tools.jar`.
`proguard_specs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन फ़ाइलों का इस्तेमाल, Proguard स्पेसिफ़िकेशन के तौर पर किया जाएगा. इनसे, Proguard के लिए इस्तेमाल की जाने वाली खास बातों के सेट के बारे में पता चलेगा. अगर आपने कोई टारगेट तय किया है, तो इस लाइब्रेरी के हिसाब से उन्हें किसी भी `android_binary` टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ आइडमपोटेंट नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि मर्ज किए गए विकल्प एक-दूसरे से अलग हों.
`runtime_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है लाइब्रेरी को सिर्फ़ फ़ाइनल बाइनरी या रनटाइम पर टेस्ट के लिए उपलब्ध कराया जा सकता है. java_library.runtime_deps देखें.
`srcjar`	लेबल; डिफ़ॉल्ट वैल्यू `None` है ऐसी JAR फ़ाइल जिसमें कंपाइल की गई JAR फ़ाइलों के लिए सोर्स कोड होता है.

java_library

नियम का सोर्स देखें

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

यह नियम, सोर्स को कंपाइल करता है और उन्हें .jar फ़ाइल में लिंक करता है.

इंप्लिसिट आउटपुट टारगेट

libname.jar: यह क्लास फ़ाइलों वाला Java संग्रह है.
libname-src.jar: यह एक ऐसा संग्रह है जिसमें सोर्स ("सोर्स जार") शामिल होते हैं.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी में लिंक की जाने वाली लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखें. ये टिप्पणियां बनाने के ज़्यादातर नियमों के तहत तय किए गए सामान्य एट्रिब्यूट में दी गई हैं. `deps` में दी गई `java_library` के नियमों से बनाए गए जार, इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके `deps`, `runtime_deps`, और `exports` का ट्रांज़िटिव क्लोज़र, रनटाइम क्लासपाथ पर होगा. इसके उलट, `data` एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल होते हैं. हालांकि, ये न तो कंपाइल-टाइम और न ही रनटाइम क्लासपाथ में शामिल होते हैं.
`srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. यह एट्रिब्यूट लगभग हमेशा ज़रूरी होता है. हालांकि, कुछ मामलों में इसकी ज़रूरत नहीं होती. इनके बारे में यहां बताया गया है. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के मामले में, आम तौर पर यह सलाह दी जाती है कि फ़ाइल के नाम के बजाय, यहां फ़ाइल जनरेट करने वाले नियम का नाम डालें. इससे न सिर्फ़ पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम, आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह बदलाव करना होगा: जनरेट करने वाले नियम का `outs`. आपको जनरेट करने के नियम को `deps` में शामिल नहीं करना चाहिए, क्योंकि यह नो-ऑप है. `.srcjar` टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उनका इस्तेमाल उसी तरह किया जाएगा जैसा सोर्स फ़ाइलों के लिए बताया गया है. यह तर्क लगभग हमेशा ज़रूरी होता है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर कोई क्लास तय करता है या आपने `runtime_deps` तर्क तय किया है, तो यह तर्क ज़रूरी नहीं होता.
`data`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है रनटाइम के दौरान, इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. `data` के बारे में सामान्य टिप्पणियां देखें. ये टिप्पणियां बनाने के ज़्यादातर नियमों के तहत तय किए गए सामान्य एट्रिब्यूट में दी गई हैं. `java_library` बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं रखता है. अगर `data` फ़ाइलें जनरेट की गई फ़ाइलें हैं, तो Bazel उन्हें जनरेट करता है. इस `java_library` पर निर्भर टेस्ट बनाते समय, Bazel `data` फ़ाइलों को रनफ़ाइल फ़ोल्डर में कॉपी या लिंक करता है.
`resources`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधन तय किए गए हैं, तो उन्हें जार में बंडल किया जाएगा. साथ ही, कंपाइल करने से बनी सामान्य `.class` फ़ाइलें भी शामिल की जाएंगी. jar फ़ाइल में मौजूद रिसॉर्स की जगह, प्रोजेक्ट स्ट्रक्चर से तय होती है. Bazel, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को देखता है. इसमें "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री का ग्रैंडचाइल्ड होता है. अगर ऐसा नहीं होता है, तो Bazel सबसे ऊपर मौजूद "java" या "javatests" नाम की डायरेक्ट्री खोजता है. इसलिए, उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमानित तरीके को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरा डायरेक्ट्री तय किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
`exported_plugins`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है उन `java_plugin`s (जैसे, एनोटेशन प्रोसेसर) की सूची जिन्हें सीधे तौर पर इस लाइब्रेरी पर निर्भर रहने वाली लाइब्रेरी में एक्सपोर्ट करना है. `java_plugin` की दी गई सूची, सीधे तौर पर इस लाइब्रेरी पर निर्भर करने वाली किसी भी लाइब्रेरी पर लागू होगी. ऐसा तब होगा, जब उस लाइब्रेरी ने `plugins` में इन लेबल का साफ़ तौर पर एलान किया हो.
`exports`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है एक्सपोर्ट की गई लाइब्रेरी. यहां लिस्टिंग के नियम जोड़ने से, वे पैरंट नियमों के लिए उपलब्ध हो जाएंगे. ऐसा लगेगा कि पैरंट नियम, इन नियमों पर साफ़ तौर पर निर्भर हैं. यह सामान्य (एक्सपोर्ट नहीं किए गए) `deps` के लिए सही नहीं है. खास जानकारी: अगर X, Y में मौजूद कोड को ऐक्सेस कर सकता है. आइए, इसे कुछ उदाहरणों की मदद से समझते हैं. मान लें कि A, B पर निर्भर है और B, C पर निर्भर है. इस मामले में, C, A की ट्रांज़िटिव डिपेंडेंसी है. इसलिए, C के सोर्स बदलने और A को फिर से बनाने पर, सब कुछ सही तरीके से फिर से बन जाएगा. हालांकि, A को C में मौजूद क्लास इस्तेमाल करने का विकल्प नहीं मिलेगा. इसके लिए, A को अपने `deps` में C के बारे में बताना होगा. इसके अलावा, B अपने `exports` एट्रिब्यूट में C के बारे में बताकर, A और A पर निर्भर किसी भी चीज़ के लिए इसे आसान बना सकता है. एक्सपोर्ट की गई लाइब्रेरी बंद करने की सुविधा, सीधे तौर पर पैरंट रूल पर लागू होती है. यहां एक और उदाहरण दिया गया है: A, B पर निर्भर करता है. B, C और D पर निर्भर करता है. साथ ही, C को एक्सपोर्ट करता है, लेकिन D को नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अब अगर C और D ने कुछ लाइब्रेरी एक्सपोर्ट की हैं, तो C' और D' के तौर पर, A सिर्फ़ C' को ऐक्सेस कर सकता है, लेकिन D' को नहीं. अहम जानकारी: एक्सपोर्ट किया गया नियम, सामान्य डिपेंडेंसी नहीं होता. पिछले उदाहरण के मुताबिक, अगर B, C को एक्सपोर्ट करता है और उसे इस्तेमाल भी करना चाहता है, तो उसे C को अपने `deps` में भी शामिल करना होगा.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. कंपाइलर के इन विकल्पों को, ग्लोबल कंपाइलर के विकल्पों के बाद javac को पास किया जाता है.
`neverlink`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है क्या इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइल करने के लिए किया जाना चाहिए, न कि रनटाइम के दौरान. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट, एक्ज़ीक्यूशन के दौरान उपलब्ध कराता है. इस तरह की लाइब्रेरी के उदाहरण, आईडीई प्लग-इन के लिए आईडीई एपीआई या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए `tools.jar` हैं. ध्यान दें कि `neverlink = 1`, कंपाइलर को इस लाइब्रेरी से कॉन्टेंट को कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता.ऐसा Java Language Specification के तहत किया जाता है. उदाहरण के लिए, `static final` के कॉन्स्टेंट `String` या प्रिमिटिव टाइप). इसलिए, रनटाइम लाइब्रेरी का इस्तेमाल तब करना चाहिए, जब वह कंपाइलेशन लाइब्रेरी के जैसी हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि वह सिर्फ़ उन जगहों पर अलग हो जहां JLS, कंपाइलर को इनलाइन करने की अनुमति नहीं देता है. साथ ही, यह JLS के सभी आने वाले वर्शन के लिए लागू होना चाहिए.
`plugins`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है कंपाइल-टाइम पर चलाने के लिए, Java कंपाइलर प्लगिन. इस एट्रिब्यूट में बताए गए हर `java_plugin` को तब चलाया जाएगा, जब यह नियम बनाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से भी प्लगिन मिल सकते हैं जो `exported_plugins` का इस्तेमाल करती हैं. इस नियम के नतीजे के तौर पर मिले जार में, प्लगिन से जनरेट किए गए संसाधन शामिल होंगे.
`proguard_specs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन फ़ाइलों का इस्तेमाल, Proguard स्पेसिफ़िकेशन के तौर पर किया जाएगा. इनसे, Proguard के लिए इस्तेमाल की जाने वाली खास बातों के सेट के बारे में पता चलेगा. अगर आपने कोई टारगेट तय किया है, तो इस लाइब्रेरी के हिसाब से उन्हें किसी भी `android_binary` टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ आइडमपोटेंट नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि मर्ज किए गए विकल्प एक-दूसरे से अलग हों.
`resource_jars`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है अब इस्तेमाल नहीं किया जा सकता: इसके बजाय, java_import और deps या runtime_deps का इस्तेमाल करें.
`resource_strip_prefix`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है Java रिसॉर्स से पाथ प्रीफ़िक्स हटाने का विकल्प. अगर इस विकल्प को चुना जाता है, तो `resources` एट्रिब्यूट में मौजूद हर फ़ाइल से पाथ प्रीफ़िक्स हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर इसे तय नहीं किया जाता है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल, `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है लाइब्रेरी को सिर्फ़ फ़ाइनल बाइनरी या रनटाइम पर टेस्ट के लिए उपलब्ध कराया जा सकता है. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, उनसे अलग, ये कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी का विश्लेषण करने वाले टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.

java_lite_proto_library

नियम का सोर्स देखें

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

java_lite_proto_library, .proto फ़ाइलों से Java कोड जनरेट करता है.

deps, proto_library के नियमों के मुताबिक होना चाहिए.

उदाहरण:

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

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

proto_library(
    name = "bar",
)

तर्क

विशेषताएं

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

deps

लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है

proto_library नियमों की सूची, जिनके लिए Java कोड जनरेट करना है.

java_proto_library

नियम का सोर्स देखें

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

java_proto_library, .proto फ़ाइलों से Java कोड जनरेट करता है.

deps, proto_library के नियमों के मुताबिक होना चाहिए.

उदाहरण:

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

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

proto_library(
    name = "foo_proto",
)

तर्क

विशेषताएं

name

नाम; ज़रूरी है

इस टारगेट के लिए यूनीक नाम.

deps

लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है

proto_library नियमों की सूची, जिनके लिए Java कोड जनरेट करना है.

java_test

नियम का सोर्स देखें

java_test(name, deps, srcs, data, resources, args, 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, plugins, resource_jars, 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)

java_test() नियम, Java टेस्ट को कंपाइल करता है. टेस्ट, आपके टेस्ट कोड के चारों ओर एक बाइनरी रैपर होता है. मुख्य क्लास को कंपाइल करने के बजाय, टेस्ट रनर के मुख्य तरीके को लागू किया जाता है.

इंप्लिसिट आउटपुट टारगेट

name.jar: यह एक Java संग्रह है.
name_deploy.jar: डिप्लॉयमेंट के लिए सही Java संग्रह. (यह सिर्फ़ तब बनाया जाता है, जब इसके लिए साफ़ तौर पर अनुरोध किया जाता है.) ज़्यादा जानकारी के लिए, name_deploy.jar java_binary से मिले आउटपुटname_deploy.jar का ब्यौरा देखें.

java_binary() आर्ग्युमेंट के बारे में सेक्शन देखें. यह नियम, जांच के सभी नियमों (*_test) के लिए उपलब्ध सभी सामान्य एट्रिब्यूट के साथ भी काम करता है.

उदाहरण

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",
    ],
)

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखें. ये टिप्पणियां, ज़्यादातर बिल्ड नियमों के तहत तय किए गए सामान्य एट्रिब्यूट में दी गई हैं.
`srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. यह एट्रिब्यूट लगभग हमेशा ज़रूरी होता है. हालांकि, कुछ मामलों में इसकी ज़रूरत नहीं होती. इनके बारे में यहां बताया गया है. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के मामले में, आम तौर पर यह सलाह दी जाती है कि फ़ाइल के नाम के बजाय, यहां फ़ाइल जनरेट करने वाले नियम का नाम डालें. इससे न सिर्फ़ पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम, आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह बदलाव करना होगा: जनरेट करने वाले नियम का `outs`. आपको जनरेट करने के नियम को `deps` में शामिल नहीं करना चाहिए, क्योंकि यह नो-ऑप है. `.srcjar` टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उनका इस्तेमाल उसी तरह किया जाएगा जैसा सोर्स फ़ाइलों के लिए बताया गया है. यह तर्क लगभग हमेशा ज़रूरी होता है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर कोई क्लास तय करता है या आपने `runtime_deps` तर्क तय किया है, तो यह तर्क ज़रूरी नहीं होता.
`resources`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधन तय किए गए हैं, तो उन्हें जार में बंडल किया जाएगा. साथ ही, कंपाइल करने से बनी सामान्य `.class` फ़ाइलें भी शामिल की जाएंगी. jar फ़ाइल में मौजूद रिसॉर्स की जगह, प्रोजेक्ट स्ट्रक्चर से तय होती है. Bazel, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को देखता है. इसमें "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री का ग्रैंडचाइल्ड होता है. अगर ऐसा नहीं होता है, तो Bazel सबसे ऊपर मौजूद "java" या "javatests" नाम की डायरेक्ट्री खोजता है. इसलिए, उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमानित तरीके को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरा डायरेक्ट्री तय किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
`classpath_resources`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई और तरीका न हो) उन संसाधनों की सूची जो Java ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का मकसद सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना है जिनके संसाधनों को क्लासपाथ पर के तौर पर ढूंढना ज़रूरी है.`"myconfig.xml"` नेमस्पेस के टकराव के खतरे की वजह से, इसे सिर्फ़ बाइनरी पर इस्तेमाल किया जा सकता है, लाइब्रेरी पर नहीं.
`create_executable`	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट रूप से `True` होता है इस सुविधा के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय, `java_single_jar` का इस्तेमाल करें.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है `META-INF/manifest.mf` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची.`_deploy.jar` इस एट्रिब्यूट के कॉन्टेंट को "बदलाव की अनुमति दें" सेटिंग के तहत बदला नहीं जा सकता*.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. कंपाइलर के इन विकल्पों को, ग्लोबल कंपाइलर के विकल्पों के बाद javac को पास किया जाता है.
`jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह $(location) और "वैरिएबल बनाएं" के विकल्प पर निर्भर करता है. साथ ही, यह बोर्न शेल टोकनाइज़ेशन पर भी निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH की परिभाषा शामिल होती है. इससे सभी डिपेंडेंट जार फ़ाइलें मिलती हैं. साथ ही, यह सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम शामिल होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के ज़रिए पार्स किए जाने वाले आर्ग्युमेंट को कमांड लाइन पर क्लासनेम से पहले तय किया जाना चाहिए. `jvm_flags` का कॉन्टेंट, रैपर स्क्रिप्ट में क्लासनेम से पहले जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`launcher`	लेबल; डिफ़ॉल्ट वैल्यू `None` है JDK में शामिल सामान्य `bin/java` प्रोग्राम के बजाय, अपने Java प्रोग्राम को चलाने के लिए किसी बाइनरी को तय करें. टारगेट `cc_binary` होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, `cc_binary` को सेट किया जा सकता है. `cc_binary`, Java Invocation API को लागू करता हो. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़ा `--java_launcher` Bazel फ़्लैग, सिर्फ़ उन `java_binary` और `java_test` टारगेट पर असर डालता है जिनमें `launcher` एट्रिब्यूट नहीं बताया गया है. ध्यान दें कि आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी. यह इस बात पर निर्भर करता है कि JDK लॉन्चर का इस्तेमाल किया जा रहा है या किसी अन्य लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां `{name}_nativedeps.so`, इस java_binary नियम का `name` एट्रिब्यूट है.`{name}` इस कॉन्फ़िगरेशन में, लिंक करने वाला व्यक्ति ऐसे कोड को नहीं हटाता है जिसका इस्तेमाल नहीं किया गया है. अगर किसी अन्य लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी को `{name}_nativedeps` नाम के बाइनरी में स्टैटिक तौर पर लिंक किया जाता है. यहां `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस मामले में, लिंक करने वाला प्रोग्राम, नतीजे के तौर पर मिले बाइनरी से ऐसे कोड को हटा देगा जिसका इस्तेमाल नहीं किया गया है. इसका मतलब है कि सिर्फ़ JNI के ज़रिए ऐक्सेस किए गए किसी भी C++ कोड को तब तक लिंक नहीं किया जा सकता, जब तक कि वह `cc_library` टारगेट `alwayslink = 1` के बारे में न बताता हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी अन्य लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, `main()` तरीके वाली क्लास का नाम. अगर किसी नियम में इस विकल्प का इस्तेमाल किया जाता है, तो उसे `srcs=[...]` सूची की ज़रूरत नहीं होती. इसलिए, इस एट्रिब्यूट की मदद से, Java लाइब्रेरी से एक एक्ज़ीक्यूटेबल बनाया जा सकता है. इसमें पहले से ही एक या उससे ज़्यादा `main()` तरीके शामिल होते हैं. इस एट्रिब्यूट की वैल्यू, क्लास का नाम है, न कि सोर्स फ़ाइल. क्लास, रनटाइम पर उपलब्ध होनी चाहिए: इसे इस नियम के तहत कंपाइल किया जा सकता है (`srcs` से) या इसे डायरेक्ट या ट्रांज़िटिव डिपेंडेंसी (`runtime_deps` या `deps` के ज़रिए) से उपलब्ध कराया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो बाइनरी, रनटाइम पर काम नहीं करेगी. बिल्ड-टाइम की कोई जांच नहीं होती.
`plugins`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है कंपाइल-टाइम पर चलाने के लिए, Java कंपाइलर प्लगिन. इस एट्रिब्यूट में बताए गए हर `java_plugin` को तब चलाया जाएगा, जब यह नियम बनाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से भी प्लगिन मिल सकते हैं जो `exported_plugins` का इस्तेमाल करती हैं. इस नियम के नतीजे के तौर पर मिले जार में, प्लगिन से जनरेट किए गए संसाधन शामिल होंगे.
`resource_jars`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है अब इस्तेमाल नहीं किया जा सकता: इसके बजाय, java_import और deps या runtime_deps का इस्तेमाल करें.
`resource_strip_prefix`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है Java रिसॉर्स से पाथ प्रीफ़िक्स हटाने का विकल्प. अगर इस विकल्प को चुना जाता है, तो `resources` एट्रिब्यूट में मौजूद हर फ़ाइल से पाथ प्रीफ़िक्स हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर इसे तय नहीं किया जाता है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल, `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है लाइब्रेरी को सिर्फ़ फ़ाइनल बाइनरी या रनटाइम पर टेस्ट के लिए उपलब्ध कराया जा सकता है. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, उनसे अलग, ये कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी का विश्लेषण करने वाले टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `0` है बिल्ड की जानकारी को बाइनरी में कोड में बदला जाए या नहीं. इन वैल्यू का इस्तेमाल किया जा सकता है: `stamp = 1`: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. भले ही, `--nostamp` बिल्ड में ऐसा न किया गया हो. इस सेटिंग का इस्तेमाल नहीं करना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर डाउनस्ट्रीम कार्रवाइयों के लिए रिमोट कैशिंग बंद हो जाती है. `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजों को बेहतर तरीके से कैश मेमोरी में सेव किया जा सकता है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की सुविधा, `--[no]stamp` फ़्लैग से कंट्रोल की जाती है. स्टैंप किए गए बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`test_class`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है यह Java क्लास, टेस्ट रनर से लोड की जाती है. डिफ़ॉल्ट रूप से, अगर इस आर्ग्युमेंट को तय नहीं किया जाता है, तो लेगसी मोड का इस्तेमाल किया जाता है. साथ ही, टेस्ट आर्ग्युमेंट का इस्तेमाल किया जाता है. पहले आर्ग्युमेंट पर फ़ॉलबैक न करने के लिए, `--nolegacy_bazel_java_test` फ़्लैग सेट करें इस एट्रिब्यूट से, उस Java क्लास का नाम तय किया जाता है जिसे इस टेस्ट के ज़रिए चलाया जाना है. इस विकल्प को सेट करने की ज़रूरत बहुत कम ही पड़ती है. इस आर्ग्युमेंट को शामिल न करने पर, टारगेट के `name` और उसके सोर्स-रूट के हिसाब से पाथ का इस्तेमाल किया जाएगा. अगर टेस्ट, किसी जाने-पहचाने सोर्स रूट से बाहर है, तो `test_class` को सेट न करने पर Bazel गड़बड़ी की सूचना देगा. JUnit3 के लिए, टेस्ट क्लास को `junit.framework.TestCase` की सबक्लास होना चाहिए. इसके अलावा, इसमें एक पब्लिक स्टैटिक `suite()` मेथड होना चाहिए, जो `junit.framework.Test` (या `Test` की सबक्लास) को दिखाता हो. JUnit4 के लिए, क्लास को `org.junit.runner.RunWith` के साथ एनोटेट किया जाना चाहिए. इस एट्रिब्यूट की मदद से, कई `java_test` नियम एक ही `Test` (`TestCase`, `TestSuite`, ...) शेयर कर सकते हैं. आम तौर पर, इसे अतिरिक्त जानकारी (जैसे, `jvm_flags=['-Dkey=value']` के ज़रिए) दी जाती है, ताकि हर मामले में इसका व्यवहार अलग-अलग हो. जैसे, टेस्ट का कोई दूसरा सबसेट चलाना. इस एट्रिब्यूट की मदद से, `javatests` ट्री के बाहर Java टेस्ट का इस्तेमाल भी किया जा सकता है.
`use_launcher`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है क्या बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए launcher एट्रिब्यूट और इससे जुड़ा `--java_launcher` फ़्लैग अनदेखा कर दिया जाएगा.
`use_testrunner`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है Java प्रोग्राम के लिए, टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करें. साथ ही, टेस्ट क्लास को टेस्ट रनर को `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर उपलब्ध कराएं. इसका इस्तेमाल, डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. डिफ़ॉल्ट व्यवहार यह है कि `java_test` नियमों के लिए टेस्ट रनर का इस्तेमाल किया जाता है और `java_binary` नियमों के लिए इसका इस्तेमाल नहीं किया जाता. ऐसा हो सकता है कि आपको यह तरीका न अपनाना पड़े. इसका इस्तेमाल, `AllTest` ऐसे नियमों के लिए किया जाता है जिन्हें किसी दूसरे नियम से लागू किया जाता है. उदाहरण के लिए, जांच शुरू करने से पहले डेटाबेस सेट अप करने के लिए. `AllTest` नियम को `java_binary` के तौर पर घोषित किया जाना चाहिए. हालांकि, इसे अब भी टेस्ट रनर का इस्तेमाल मुख्य एंट्री पॉइंट के तौर पर करना चाहिए. टेस्ट रनर क्लास के नाम को `main_class` एट्रिब्यूट का इस्तेमाल करके बदला जा सकता है.

java_package_configuration

नियम का सोर्स देखें

java_package_configuration(name, data, compatible_with, deprecation, distribs, features, javacopts, licenses, packages, restricted_to, tags, target_compatible_with, testonly, visibility)

पैकेज के सेट पर लागू किया जाने वाला कॉन्फ़िगरेशन. कॉन्फ़िगरेशन को java_toolchain.javacopts में जोड़ा जा सकता है.

उदाहरण:

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",
    ]
)

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`data`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है उन फ़ाइलों की सूची जिनकी ज़रूरत इस कॉन्फ़िगरेशन को रनटाइम में होती है.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java कंपाइलर फ़्लैग.
`packages`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है `package_group` का वह सेट जिस पर कॉन्फ़िगरेशन लागू होना चाहिए.

java_plugin

नियम का सोर्स देखें

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

java_plugin, Bazel की मदद से चलाए जाने वाले Java कंपाइलर के लिए प्लगिन तय करता है. फ़िलहाल, सिर्फ़ एनोटेशन प्रोसेसर वाले प्लगिन इस्तेमाल किए जा सकते हैं. java_library या java_binary नियम, plugins एट्रिब्यूट के ज़रिए प्लगिन पर निर्भर रहकर उन्हें चला सकते हैं. java_library, उन लाइब्रेरी में प्लगिन अपने-आप एक्सपोर्ट कर सकता है जो सीधे तौर पर exported_plugins पर निर्भर करती हैं.

इंप्लिसिट आउटपुट टारगेट

libname.jar: यह एक Java संग्रह है.

आर्ग्युमेंट, java_library फ़ंक्शन के आर्ग्युमेंट की तरह ही होते हैं. हालांकि, इसमें processor_class आर्ग्युमेंट को जोड़ा जाता है.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी में लिंक की जाने वाली लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखें. ये टिप्पणियां बनाने के ज़्यादातर नियमों के तहत तय किए गए सामान्य एट्रिब्यूट में दी गई हैं. `deps` में दी गई `java_library` के नियमों से बनाए गए जार, इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके `deps`, `runtime_deps`, और `exports` का ट्रांज़िटिव क्लोज़र, रनटाइम क्लासपाथ पर होगा. इसके उलट, `data` एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल होते हैं. हालांकि, ये न तो कंपाइल-टाइम और न ही रनटाइम क्लासपाथ में शामिल होते हैं.
`srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. यह एट्रिब्यूट लगभग हमेशा ज़रूरी होता है. हालांकि, कुछ मामलों में इसकी ज़रूरत नहीं होती. इनके बारे में यहां बताया गया है. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के मामले में, आम तौर पर यह सलाह दी जाती है कि फ़ाइल के नाम के बजाय, यहां फ़ाइल जनरेट करने वाले नियम का नाम डालें. इससे न सिर्फ़ पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम, आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह बदलाव करना होगा: जनरेट करने वाले नियम का `outs`. आपको जनरेट करने के नियम को `deps` में शामिल नहीं करना चाहिए, क्योंकि यह नो-ऑप है. `.srcjar` टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उनका इस्तेमाल उसी तरह किया जाएगा जैसा सोर्स फ़ाइलों के लिए बताया गया है. यह तर्क लगभग हमेशा ज़रूरी होता है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर कोई क्लास तय करता है या आपने `runtime_deps` तर्क तय किया है, तो यह तर्क ज़रूरी नहीं होता.
`data`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है रनटाइम के दौरान, इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. `data` के बारे में सामान्य टिप्पणियां देखें. ये टिप्पणियां बनाने के ज़्यादातर नियमों के तहत तय किए गए सामान्य एट्रिब्यूट में दी गई हैं. `java_library` बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं रखता है. अगर `data` फ़ाइलें जनरेट की गई फ़ाइलें हैं, तो Bazel उन्हें जनरेट करता है. इस `java_library` पर निर्भर टेस्ट बनाते समय, Bazel `data` फ़ाइलों को रनफ़ाइल फ़ोल्डर में कॉपी या लिंक करता है.
`resources`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधन तय किए गए हैं, तो उन्हें जार में बंडल किया जाएगा. साथ ही, कंपाइल करने से बनी सामान्य `.class` फ़ाइलें भी शामिल की जाएंगी. jar फ़ाइल में मौजूद रिसॉर्स की जगह, प्रोजेक्ट स्ट्रक्चर से तय होती है. Bazel, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को देखता है. इसमें "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री का ग्रैंडचाइल्ड होता है. अगर ऐसा नहीं होता है, तो Bazel सबसे ऊपर मौजूद "java" या "javatests" नाम की डायरेक्ट्री खोजता है. इसलिए, उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमानित तरीके को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरा डायरेक्ट्री तय किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
`generates_api`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है यह एट्रिब्यूट, एनोटेशन प्रोसेसर को मार्क करता है. ये प्रोसेसर, एपीआई कोड जनरेट करते हैं. अगर कोई नियम, एनोटेशन प्रोसेसर जनरेट करने वाले एपीआई का इस्तेमाल करता है, तो उस पर निर्भर अन्य नियम, जनरेट किए गए कोड को सिर्फ़ तब रेफ़र कर सकते हैं, जब उनके कंपाइल करने की कार्रवाइयां, जनरेट करने वाले नियम के बाद शेड्यूल की गई हों. इस एट्रिब्यूट से Bazel को यह निर्देश मिलता है कि --java_header_compilation चालू होने पर, शेड्यूल करने से जुड़ी पाबंदियां लागू करें. चेतावनी: इस एट्रिब्यूट से, बिल्ड की परफ़ॉर्मेंस पर असर पड़ता है. इसका इस्तेमाल सिर्फ़ तब करें, जब ज़रूरी हो.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. कंपाइलर के इन विकल्पों को, ग्लोबल कंपाइलर के विकल्पों के बाद javac को पास किया जाता है.
`neverlink`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है क्या इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइल करने के लिए किया जाना चाहिए, न कि रनटाइम के दौरान. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट, एक्ज़ीक्यूशन के दौरान उपलब्ध कराता है. इस तरह की लाइब्रेरी के उदाहरण, आईडीई प्लग-इन के लिए आईडीई एपीआई या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए `tools.jar` हैं. ध्यान दें कि `neverlink = 1`, कंपाइलर को इस लाइब्रेरी से कॉन्टेंट को कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता.ऐसा Java Language Specification के तहत किया जाता है. उदाहरण के लिए, `static final` के कॉन्स्टेंट `String` या प्रिमिटिव टाइप). इसलिए, रनटाइम लाइब्रेरी का इस्तेमाल तब करना चाहिए, जब वह कंपाइलेशन लाइब्रेरी के जैसी हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि वह सिर्फ़ उन जगहों पर अलग हो जहां JLS, कंपाइलर को इनलाइन करने की अनुमति नहीं देता है. साथ ही, यह JLS के सभी आने वाले वर्शन के लिए लागू होना चाहिए.
`output_licenses`	लाइसेंस का टाइप; डिफ़ॉल्ट रूप से `["none"]` पर सेट होता है `common attributes` देखें
`plugins`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है कंपाइल-टाइम पर चलाने के लिए, Java कंपाइलर प्लगिन. इस एट्रिब्यूट में बताए गए हर `java_plugin` को तब चलाया जाएगा, जब यह नियम बनाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से भी प्लगिन मिल सकते हैं जो `exported_plugins` का इस्तेमाल करती हैं. इस नियम के नतीजे के तौर पर मिले जार में, प्लगिन से जनरेट किए गए संसाधन शामिल होंगे.
`processor_class`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है प्रोसेसर क्लास, क्लास का पूरी तरह से क्वालिफ़ाइड टाइप होता है. Java कंपाइलर को एनोटेशन प्रोसेसर के एंट्री पॉइंट के तौर पर इसका इस्तेमाल करना चाहिए. अगर इसे तय नहीं किया जाता है, तो यह नियम Java कंपाइलर की एनोटेशन प्रोसेसिंग में एनोटेशन प्रोसेसर का योगदान नहीं देगा. हालांकि, इसका रनटाइम क्लासपाथ अब भी कंपाइलर के एनोटेशन प्रोसेसर पाथ में शामिल किया जाएगा. (इसका इस्तेमाल मुख्य रूप से गड़बड़ी वाले प्लगिन करते हैं. इन्हें एनोटेशन प्रोसेसर पाथ से लोड किया जाता है. इसके लिए, java.util.ServiceLoader का इस्तेमाल किया जाता है.)
`proguard_specs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इन फ़ाइलों का इस्तेमाल, Proguard स्पेसिफ़िकेशन के तौर पर किया जाएगा. इनसे, Proguard के लिए इस्तेमाल की जाने वाली खास बातों के सेट के बारे में पता चलेगा. अगर आपने कोई टारगेट तय किया है, तो इस लाइब्रेरी के हिसाब से उन्हें किसी भी `android_binary` टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ आइडमपोटेंट नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि मर्ज किए गए विकल्प एक-दूसरे से अलग हों.
`resource_jars`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है अब इस्तेमाल नहीं किया जा सकता: इसके बजाय, java_import और deps या runtime_deps का इस्तेमाल करें.
`resource_strip_prefix`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है Java रिसॉर्स से पाथ प्रीफ़िक्स हटाने का विकल्प. अगर इस विकल्प को चुना जाता है, तो `resources` एट्रिब्यूट में मौजूद हर फ़ाइल से पाथ प्रीफ़िक्स हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर इसे तय नहीं किया जाता है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल, `foo/bar/a.txt` पर मौजूद होगी.

java_runtime

नियम का सोर्स देखें

java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, features, hermetic_srcs, java, java_home, lib_ct_sym, lib_modules, licenses, restricted_to, tags, target_compatible_with, testonly, version, visibility)

यह कुकी, Java रनटाइम के लिए कॉन्फ़िगरेशन तय करती है.

उदाहरण:

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

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है रनटाइम में मौजूद सभी फ़ाइलें.
`default_cds`	लेबल; डिफ़ॉल्ट वैल्यू `None` है हर्मेटिक `java_runtime` के लिए डिफ़ॉल्ट सीडीएस संग्रह. जब किसी `java_binary` टारगेट के लिए hermetic चालू होता है और अगर टारगेट, `classlist` एट्रिब्यूट की वैल्यू तय करके अपना सीडीएस संग्रह उपलब्ध नहीं कराता है, तो `java_runtime` डिफ़ॉल्ट सीडीएस को hermetic डिप्लॉय JAR में पैकेज किया जाता है.
`hermetic_srcs`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है हर्मेटिक डिप्लॉयमेंट के लिए, रनटाइम में मौजूद फ़ाइलें ज़रूरी होती हैं.
`java`	लेबल; डिफ़ॉल्ट वैल्यू `None` है java एक्ज़ीक्यूटेबल का पाथ.
`java_home`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है रनटाइम के रूट का पाथ. "मेक" वैरिएबल के हिसाब से बदलाव किया जा सकता है. अगर यह पाथ ऐब्सलूट है, तो नियम एक नॉन-हर्मेटिक Java रनटाइम को दिखाता है. इसका पाथ जाना-पहचाना होता है. ऐसे में, `srcs` और `java` एट्रिब्यूट की वैल्यू खाली होनी चाहिए.
`lib_ct_sym`	लेबल; डिफ़ॉल्ट वैल्यू `None` है lib/ct.sym फ़ाइल, `--release` के साथ कंपाइल करने के लिए ज़रूरी है. अगर यह जानकारी नहीं दी गई है और `srcs` में सिर्फ़ एक ऐसी फ़ाइल है जिसका पाथ `/lib/ct.sym` से खत्म होता है, तो उस फ़ाइल का इस्तेमाल किया जाता है.
`lib_modules`	लेबल; डिफ़ॉल्ट वैल्यू `None` है यह lib/modules फ़ाइल, हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी होती है.
`version`	पूर्णांक; डिफ़ॉल्ट वैल्यू `0` है Java रनटाइम का फ़ीचर वर्शन. इसका मतलब है कि `Runtime.version().feature()` से मिली पूर्णांक वैल्यू.

java_toolchain

नियम का सोर्स देखें

java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_with, deprecation, deps_checker, distribs, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jvm_opts, licenses, oneversion, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, resourcejar, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, tools, turbine_data, turbine_jvm_opts, visibility, xlint)

इससे Java कंपाइलर के लिए कॉन्फ़िगरेशन तय किया जाता है. --java_toolchain आर्ग्युमेंट का इस्तेमाल करके, यह बदला जा सकता है कि कौनसी टूलचेन इस्तेमाल की जानी चाहिए. आम तौर पर, आपको इस तरह के नियम नहीं लिखने चाहिए. हालांकि, अगर आपको अपने Java कंपाइलर को ट्यून करना है, तो ऐसा किया जा सकता है.

उदाहरण

इसका एक सामान्य उदाहरण यह होगा:

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",
)

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`android_lint_data`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है android_lint_jvm_opts में लेबल-एक्सपेंशन के लिए उपलब्ध टूल के लेबल.
`android_lint_jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है Android Lint को चालू करते समय, JVM के लिए आर्ग्युमेंट की सूची.
`android_lint_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है Android Lint के तर्कों की सूची.
`android_lint_package_configuration`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है Android Lint कॉन्फ़िगरेशन, जिसे तय किए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
`android_lint_runner`	लेबल; डिफ़ॉल्ट वैल्यू `None` है Android Lint runner का लेबल, अगर कोई है.
`bootclasspath`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java के टारगेट बूटक्लाथपाथ की एंट्री. यह javac के -bootclasspath फ़्लैग के बराबर है.
`deps_checker`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है ImportDepsChecker को डिप्लॉय करने वाले JAR का लेबल.
`forcibly_disable_header_compilation`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है यह --java_header_compilation को बदलकर, उन प्लैटफ़ॉर्म पर हेडर कंपाइलेशन की सुविधा बंद कर देता है जिन पर यह काम नहीं करती. जैसे, JDK 7 Bazel.
`genclass`	लेबल की सूची; ज़रूरी है GenClass को डिप्लॉय करने वाले जार का लेबल.
`header_compiler`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है हेडर कंपाइलर का लेबल. अगर --java_header_compilation चालू है, तो यह विकल्प ज़रूरी है.
`header_compiler_direct`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है हेडर कंपाइलर का ऐसा लेबल जिसका इस्तेमाल डायरेक्ट क्लासपाथ ऐक्शन के लिए किया जा सकता है. हालांकि, इसमें एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर शामिल नहीं होते. यह टूल, एनोटेशन प्रोसेसिंग की सुविधा के साथ काम नहीं करता.
`ijar`	लेबल की सूची; ज़रूरी है ijar एक्ज़ीक्यूटेबल का लेबल.
`jacocorunner`	लेबल; डिफ़ॉल्ट वैल्यू `None` है JacocoCoverageRunner के डिप्लॉय जार का लेबल.
`java_runtime`	लेबल; ज़रूरी है इस टूलचेन के साथ इस्तेमाल किया जाने वाला java_runtime. यह एक्ज़ीक्यूशन कॉन्फ़िगरेशन में डिफ़ॉल्ट रूप से java_runtime पर सेट होता है.
`javabuilder`	लेबल की सूची; ज़रूरी है JavaBuilder डिप्लॉय जार का लेबल.
`javabuilder_data`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है javabuilder_jvm_opts में लेबल-एक्सपेंशन के लिए उपलब्ध डेटा के लेबल.
`javabuilder_jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है JavaBuilder को शुरू करते समय, JVM के लिए आर्ग्युमेंट की सूची.
`javac_supports_multiplex_workers`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है अगर JavaBuilder, मल्टीप्लेक्स परसिस्टेंट वर्कर के तौर पर काम करता है, तो यह वैल्यू सही होती है. अगर ऐसा नहीं होता है, तो यह वैल्यू गलत होती है.
`javac_supports_worker_multiplex_sandboxing`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है अगर JavaBuilder, मल्टीप्लेक्स सैंडबॉक्सिंग के साथ काम करता है, तो यह वैल्यू सही होती है. अगर JavaBuilder, मल्टीप्लेक्स सैंडबॉक्सिंग के साथ काम नहीं करता है, तो यह वैल्यू गलत होती है.
`javac_supports_workers`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है अगर JavaBuilder, परसिस्टेंट वर्कर के तौर पर काम कर सकता है, तो यह सही है. अगर ऐसा नहीं है, तो यह गलत है.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java कंपाइलर के लिए अतिरिक्त तर्कों की सूची. Java कंपाइलर के फ़्लैग की पूरी सूची देखने के लिए, कृपया Java कंपाइलर के दस्तावेज़ देखें.
`jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java कंपाइलर को शुरू करते समय, JVM के लिए आर्ग्युमेंट की सूची. इस विकल्प के लिए संभावित फ़्लैग की पूरी सूची देखने के लिए, कृपया Java वर्चुअल मशीन का दस्तावेज़ देखें.
`oneversion`	लेबल; डिफ़ॉल्ट वैल्यू `None` है नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) वाले एक वर्शन के बाइनरी का लेबल.
`oneversion_allowlist_for_tests`	लेबल; डिफ़ॉल्ट वैल्यू `None` है टेस्ट के लिए, एक वर्शन वाली अनुमति वाली सूची का लेबल.
`oneversion_whitelist`	लेबल; डिफ़ॉल्ट वैल्यू `None` है एक वर्शन वाली वाइटलिस्ट का लेबल.
`package_configuration`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है कॉन्फ़िगरेशन, जिसे तय किए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
`proguard_allowlister`	लेबल; डिफ़ॉल्ट वैल्यू `"@bazel_tools//tools/jdk:proguard_whitelister"` है Proguard allowlister का लेबल.
`resourcejar`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है संसाधन जार बिल्डर के एक्ज़ीक्यूटेबल का लेबल.
`singlejar`	लेबल की सूची; ज़रूरी है SingleJar डिप्लॉय जार का लेबल.
`source_version`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है Java सोर्स वर्शन (जैसे, '6' या '7'). इससे यह तय होता है कि Java सोर्स कोड में किस तरह के कोड स्ट्रक्चर इस्तेमाल किए जा सकते हैं.
`target_version`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है Java का टारगेट वर्शन (उदाहरण के लिए, '6' या '7'). इससे यह तय होता है कि क्लास को किस Java रनटाइम के लिए बनाया जाना चाहिए.
`timezone_data`	लेबल; डिफ़ॉल्ट वैल्यू `None` है टाइमज़ोन का डेटा रखने वाले संसाधन जार का लेबल. अगर इसे सेट किया जाता है, तो टाइमज़ोन का डेटा, सभी java_binary नियमों की रनटाइम डिपेंडेंसी के तौर पर जोड़ा जाता है.
`tools`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है jvm_opts में लेबल-एक्सपेंशन के लिए उपलब्ध टूल के लेबल.
`turbine_data`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है turbine_jvm_opts में लेबल-एक्सपेंशन के लिए उपलब्ध डेटा के लेबल.
`turbine_jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है टर्बाइन को चालू करते समय, JVM के लिए आर्ग्युमेंट की सूची.
`xlint`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है चेतावनी की सूची, जिसे डिफ़ॉल्ट सूची में जोड़ा या हटाया जा सकता है. इसे हटाने के लिए, इससे पहले डैश का इस्तेमाल करें. ज़्यादा जानकारी के लिए, कृपया -Xlint विकल्पों के बारे में Javac का दस्तावेज़ देखें.

Java के नियम संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

नियम

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 के नियम