Java के नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

• 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 फ़ाइल") बनाता है. साथ ही, नियम के नाम वाली एक रैपर शेल स्क्रिप्ट भी बनाता है. रैपर शेल स्क्रिप्ट, क्लासपाथ का इस्तेमाल करती है. इसमें कई चीज़ों के साथ-साथ, हर उस लाइब्रेरी के लिए एक jar फ़ाइल शामिल होती है जिस पर बाइनरी निर्भर करती है. रैपर शेल स्क्रिप्ट चलाते समय, बेज़ेल के --java_runtime_version फ़्लैग के ज़रिए बताए गए वर्शन के मुकाबले, किसी भी खाली JAVABIN एनवायरमेंट वैरिएबल को प्राथमिकता दी जाएगी.

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

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

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

  अपने नियम के लिए <name>_deploy.jar टारगेट बनाने पर, एक ऐसी jar फ़ाइल बनती है जिसमें एक मेनिफ़ेस्ट होता है. इसकी मदद से, इसे java -jar कमांड या रैपर स्क्रिप्ट के --singlejar विकल्प के साथ चलाया जा सकता है. java -jar के बजाय, रैपर स्क्रिप्ट का इस्तेमाल करना बेहतर होता है, क्योंकि यह JVM फ़्लैग और नेटिव लाइब्रेरी को लोड करने के विकल्पों को भी पास करती है.

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

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

• name_deploy-src.jar: एक संग्रह, जिसमें टारगेट के अस्थायी तौर पर बंद होने से इकट्ठा किए गए सोर्स शामिल होते हैं. ये deploy.jar की क्लास से मेल खाएंगे. हालांकि, उन जगह को छोड़कर जहां जार के पास मिलता-जुलता कोई सोर्स जार नहीं होता है.

java_binary नियम में srcs के बिना 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 में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद एक "resources" डायरेक्ट्री ग्रैंडचाइल्ड) को खोजता है. अगर वह नहीं मिलता है, तो Basel, फिर "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 से लोड किया जाएगा. इस एट्रिब्यूट की वैल्यू सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉय किए गए jar) से उन सभी डिपेंडेंसी को हटा दिया जाता है जो इस बाइनरी और deploy_env में बताए गए टारगेट के बीच शेयर की जाती हैं.
deploy_manifest_lines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] *_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट की जगह नहीं है, लेकिन इसकी जगह "वैरिएबल बनाएं" लागू होगा.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.
jvm_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH परिभाषा शामिल होती है, ताकि सभी डिपेंडेंट (आश्रित) jar ढूंढे जा सकें. साथ ही, यह सही Java इंटरप्रेटर को भी चालू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम और उसके बाद "$@" होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM से पार्स करने के लिए बनाए गए आर्ग्युमेंट, कमांड लाइन में क्लास नेम से पहले तय किए जाने चाहिए. क्लास का नाम शामिल किए जाने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
launcher	लेबल; डिफ़ॉल्ट None है JDK में शामिल सामान्य bin/java प्रोग्राम के बजाय, अपने Java प्रोग्राम को चलाने के लिए इस्तेमाल की जाने वाली बाइनरी तय करें. टारगेट एक cc_binary होना चाहिए. Java इनवोकेशन एपीआई को लागू करने वाले किसी भी cc_binary को इस एट्रिब्यूट की वैल्यू के तौर पर तय किया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते --java_launcher बेज़ल फ़्लैग का असर सिर्फ़ उन java_binary और java_test टारगेट पर पड़ता है जिन्होंने launcher एट्रिब्यूट की जानकारी नहीं दी है. ध्यान दें कि JDK लॉन्चर या किसी अन्य लॉन्चर का इस्तेमाल करने पर, आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को {name}_nativedeps.so नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां {name}, इस java_binary नियम का 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 की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये 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 इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए करें, न कि रनटाइम के दौरान. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट से, प्रोग्राम के रन होने के दौरान उपलब्ध कराया जाएगा. इस तरह की लाइब्रेरी के उदाहरण: IDE प्लग-इन के लिए, IDE API या स्टैंडर्ड 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: सोर्स ("सोर्स jar") वाला संग्रह.

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से लिंक की जाने वाली लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. deps में दिए गए java_library नियमों से बनाए गए jar, इस नियम के संकलन के समय के क्लासपथ पर होंगे. इसके अलावा, उनके deps, runtime_deps, और exports के ट्रांज़िटिव क्लोज़र, रनटाइम क्लासपाथ पर होंगे. इसके उलट, data एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल होते हैं. हालांकि, ये टारगेट, Compile-time और रनटाइम क्लासपाथ, दोनों में शामिल नहीं होते.
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 में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद एक "resources" डायरेक्ट्री ग्रैंडचाइल्ड) को खोजता है. अगर वह नहीं मिलता है, तो Baज़र, "java" या "javatests" नाम की सबसे टॉप डायरेक्ट्री को खोजता है. उदाहरण के लिए, उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
exported_plugins	लेबल की सूची; डिफ़ॉल्ट [] है उन लाइब्रेरी में एक्सपोर्ट करने के लिए java_plugins (जैसे, एनोटेशन प्रोसेसर) की सूची जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं. java_plugin की बताई गई सूची, उन सभी लाइब्रेरी पर लागू की जाएगी जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं. ऐसा ठीक वैसे ही होगा जैसे उस लाइब्रेरी ने plugins में इन लेबल का साफ़ तौर पर एलान किया हो.
exports	लेबल की सूची; डिफ़ॉल्ट [] है एक्सपोर्ट की गई लाइब्रेरी. यहां लिस्टिंग के नियमों को शामिल करने से, वे पैरंट रूल के लिए उपलब्ध हो जाएंगे. ऐसा तब होगा, जब पैरंट ने साफ़ तौर पर इन नियमों पर निर्भरता दिखाई हो. यह रेगुलर (एक्सपोर्ट नहीं किए गए) deps के लिए सही नहीं है. खास जानकारी: नियम X, Y में मौजूद कोड को ऐक्सेस कर सकता है. ऐसा तब होता है, जब उनके बीच ऐसा डिपेंडेंसी पाथ मौजूद हो जो deps एज से शुरू होता हो और उसके बाद शून्य या उससे ज़्यादा exports एज हों. इसे समझाने के लिए हम कुछ उदाहरण देखते हैं. मान लें कि 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 में भी C को शामिल करना होगा.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.
neverlink	बूलियन; डिफ़ॉल्ट तौर पर False इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान भी. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट, प्रोग्राम के दौरान उपलब्ध कराएगा. ऐसी लाइब्रेरी के उदाहरणों में, IDE प्लग-इन के लिए IDE एपीआई या स्टैंडर्ड 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 की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये 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 कोड जनरेट करने वाले proto_library नियमों की सूची.

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 कोड जनरेट करने वाले proto_library नियमों की सूची.

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 संग्रह. (इसे सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो.) ज़्यादा जानकारी के लिए, 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 जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट होने वाली सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. जार फ़ाइल के अंदर मौजूद रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर के हिसाब से तय होती है. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद एक "resources" डायरेक्ट्री ग्रैंडचाइल्ड) को खोजता है. अगर वह नहीं मिलता है, तो Baज़र, "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 फ़ाइल में जोड़ने के लिए लाइनों की सूची, जो *_deploy.jar टारगेट के लिए जनरेट हुई है. इस एट्रिब्यूट के कॉन्टेंट में, "वैरिएबल बनाएं" विकल्प का इस्तेमाल करके बदलाव नहीं किया जा सकता.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
jvm_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH परिभाषा शामिल होती है, ताकि सभी डिपेंडेंट (आश्रित) jar ढूंढे जा सकें. साथ ही, यह सही Java इंटरप्रेटर को भी चालू करती है. रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, "$@" होता है, ताकि आप क्लासनाम के बाद दूसरे आर्ग्युमेंट को पास कर सकें. हालांकि, JVM के पास पार्स करने के लिए, कमांड लाइन पर क्लास के नाम से पहले आर्ग्युमेंट होने चाहिए. क्लास का नाम शामिल किए जाने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
launcher	लेबल; डिफ़ॉल्ट None है JDK में शामिल सामान्य bin/java प्रोग्राम के बजाय, अपने Java प्रोग्राम को चलाने के लिए इस्तेमाल किए जाने वाले बाइनरी को तय करें. टारगेट एक cc_binary होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, Java Invocation API को लागू करने वाला कोई भी cc_binary दिया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़े --java_launcher Bazel फ़्लैग का असर सिर्फ़ उन java_binary और java_test टारगेट पर पड़ता है जिनके लिए न launcher एट्रिब्यूट तय किया गया है. ध्यान दें कि JDK लॉन्चर या किसी अन्य लॉन्चर का इस्तेमाल करने पर, आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को {name}_nativedeps.so नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां {name}, इस java_binary नियम का 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 की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये 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, Basel के चलाए जा रहे Java कंपाइलर के लिए प्लगिन तय करता है. फ़िलहाल, सिर्फ़ एनोटेशन प्रोसेसर प्लग इन इस्तेमाल किए जा सकते हैं. java_library या java_binary नियम, plugins एट्रिब्यूट के ज़रिए प्लग इन चला सकता है. java_library, exported_plugins का इस्तेमाल करके, प्लग इन को उन लाइब्रेरी में भी अपने-आप एक्सपोर्ट कर सकता है जो सीधे तौर पर उस पर निर्भर हैं.

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

• libname.jar: Java का संग्रह.

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से लिंक की जाने वाली लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. deps में दिए गए java_library नियमों से बनाए गए jar, इस नियम के संकलन के समय के क्लासपथ पर होंगे. इसके अलावा, उनके deps, runtime_deps, और exports के ट्रांज़िटिव क्लोज़र, रनटाइम क्लासपाथ पर होंगे. इसके उलट, data एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल होते हैं. हालांकि, ये टारगेट, Compile-time और रनटाइम क्लासपाथ, दोनों में शामिल नहीं होते.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की जाने वाली सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. .java टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई .java फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को आसानी से अडजस्ट किया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का outs. आपको deps में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम नहीं करता. .srcjar टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर genrule या filegroup) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए बताया गया है. यह आर्ग्युमेंट करीब-करीब हमेशा ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपाथ पर क्लास के बारे में बताता हो या आप runtime_deps आर्ग्युमेंट के बारे में बताते हों.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाकर data के बारे में सामान्य टिप्पणियां देखें. java_library बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं डालता. अगर data फ़ाइलें जनरेट की गई फ़ाइलें हैं, तो Bazel उन्हें जनरेट करता है. इस java_library Baze सिस्टम पर आधारित टेस्ट बनाते समय, data फ़ाइलों को रनफ़ाइल एरिया में कॉपी या लिंक किया जाता है.
resources	लेबल की सूची; डिफ़ॉल्ट [] है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट होने वाली सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद एक "resources" डायरेक्ट्री ग्रैंडचाइल्ड) को खोजता है. अगर वह नहीं मिलता है, तो Baज़र, "java" या "javatests" नाम की सबसे टॉप डायरेक्ट्री को खोजता है. उदाहरण के लिए, उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
generates_api	बूलियन; डिफ़ॉल्ट तौर पर False यह एट्रिब्यूट, एनोटेशन प्रोसेसर को मार्क करता है, जो एपीआई कोड जनरेट करते हैं. अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो उस पर निर्भर अन्य नियम, जनरेट किए गए कोड का रेफ़रंस सिर्फ़ तब दे सकते हैं, जब उनके कोड को इकट्ठा करने की कार्रवाइयां, जनरेट करने वाले नियम के बाद शेड्यूल की गई हों. --java_header_compilation चालू होने पर, यह एट्रिब्यूट बेज़ल को शेड्यूलिंग कंस्ट्रेंट लागू करने का निर्देश देता है. चेतावनी: इस एट्रिब्यूट से बिल्ड की परफ़ॉर्मेंस पर असर पड़ता है. इसलिए, इसका इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर करें.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
neverlink	बूलियन; डिफ़ॉल्ट तौर पर False इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान भी. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट, प्रोग्राम के दौरान उपलब्ध कराएगा. ऐसी लाइब्रेरी के उदाहरणों में, IDE प्लग-इन के लिए IDE एपीआई या स्टैंडर्ड 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 या बनाए गए रनटाइम_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 के लिए डिफ़ॉल्ट CDS संग्रह. जब किसी java_binary टारगेट के लिए, हेर्मेटिक डिप्लॉय JAR चालू होता है और टारगेट, classlist एट्रिब्यूट की मदद से अपना सीडीएस संग्रह नहीं देता है, तो java_runtime डिफ़ॉल्ट सीडीएस को हेर्मेटिक डिप्लॉय JAR में पैकेज किया जाता है.
hermetic_srcs	लेबल की सूची; डिफ़ॉल्ट [] है हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी रनटाइम में फ़ाइलें.
java	लेबल; डिफ़ॉल्ट None है Java की एक्ज़ीक्यूट की जा सकने वाली फ़ाइल का पाथ.
java_home	स्ट्रिंग; डिफ़ॉल्ट रूप से "" रनटाइम के रूट का पाथ. "बनाएं" वैरिएबल के विकल्प पर निर्भर करता है. अगर यह पाथ एब्सोलूट है, तो नियम से पता चलता है कि यह एक ऐसा Java रनटाइम है जो पूरी तरह से सुरक्षित नहीं है और जिसका पाथ आम तौर पर जाना जाता है. इस मामले में, srcs और java एट्रिब्यूट खाली होने चाहिए.
lib_ct_sym	लेबल; डिफ़ॉल्ट None है --release के साथ कंपाइल करने के लिए, lib/ct.sym फ़ाइल की ज़रूरत होती है. अगर इसके बारे में नहीं बताया गया है और 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_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 लिंट कॉन्फ़िगरेशन, जिसे बताए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
android_lint_runner	लेबल; डिफ़ॉल्ट None है Android Lint Runner का लेबल, अगर कोई है.
bootclasspath	लेबल की सूची; डिफ़ॉल्ट [] है Java टारगेट के bootclasspath की एंट्री. javac के -bootclasspath फ़्लैग के मुताबिक.
deps_checker	लेबल की सूची; डिफ़ॉल्ट [] है ImportDepsChecker डिप्लॉय किए गए jar का लेबल.
forcibly_disable_header_compilation	बूलियन; डिफ़ॉल्ट तौर पर False --java_header_compilation को बदलकर, उन प्लैटफ़ॉर्म पर हेडर कंपाइलेशन की सुविधा बंद की जा सकती है जिन पर यह काम नहीं करता. जैसे, JDK 7 Bazel.
genclass	लेबल की सूची; ज़रूरी है GenClass डिप्लॉय किए गए jar का लेबल.
header_compiler	लेबल की सूची; डिफ़ॉल्ट [] है हेडर कंपाइलर का लेबल. --java_header_compilation चालू होने पर ज़रूरी है.
header_compiler_direct	लेबल की सूची; डिफ़ॉल्ट [] है हेडर कंपाइलर का वैकल्पिक लेबल, जिसका इस्तेमाल सीधे क्लासपथ ऐक्शन के लिए किया जाता है. इन ऐक्शन में, एपीआई जनरेट करने वाले किसी एनोटेशन प्रोसेसर को शामिल नहीं किया जाता. इस टूल में एनोटेशन प्रोसेसिंग की सुविधा काम नहीं करती.
ijar	लेबल की सूची; ज़रूरी है ijar एक्सीक्यूटेबल का लेबल.
jacocorunner	लेबल; डिफ़ॉल्ट None है JacocoCoverageRunner डिप्लॉय किए गए jar का लेबल.
java_runtime	लेबल; ज़रूरी है इस टूलचेन का इस्तेमाल करने के लिए java_runtime. यह डिफ़ॉल्ट रूप से, एक्ज़ीक्यूशन कॉन्फ़िगरेशन में java_runtime पर सेट होता है.
javabuilder	लेबल की सूची; ज़रूरी है JavaBuilder डिप्लॉय jar का लेबल.
javabuilder_data	लेबल की सूची; डिफ़ॉल्ट [] है javabuilder_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
javabuilder_jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] Javaबिल्डर को शुरू करते समय JVM के लिए आर्ग्युमेंट की सूची.
javac_supports_multiplex_workers	बूलियन; डिफ़ॉल्ट तौर पर True अगर JavaBuilder, मल्टीप्लेक्स पर्सिस्टेंट वर्कर्स के तौर पर काम करता है, तो True. अगर नहीं करता है, तो False.
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	लेबल की सूची; डिफ़ॉल्ट [] है संसाधन के jar बिल्डर के लिए, एक्सीक्यूटेबल का लेबल.
singlejar	लेबल की सूची; ज़रूरी है SingleJar डिप्लॉय jar का लेबल.
source_version	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Java सोर्स का वर्शन (उदाहरण के लिए, '6' या '7'). इससे पता चलता है कि Java सोर्स कोड में कोड स्ट्रक्चर के कौनसे सेट इस्तेमाल किए जा सकते हैं.
target_version	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Java का टारगेट वर्शन (उदाहरण के लिए, '6' या '7'). इससे पता चलता है कि क्लास को किस Java रनटाइम के लिए बनाया जाना चाहिए.
timezone_data	लेबल; डिफ़ॉल्ट None है टाइमज़ोन डेटा वाले रिसॉर्स जर्स का लेबल. अगर यह नीति सेट की जाती है, तो टाइमज़ोन डेटा को सभी java_binary नियमों के लिए साफ़ तौर पर रनटाइम डिपेंडेंसी के तौर पर जोड़ा जाता है.
tools	लेबल की सूची; डिफ़ॉल्ट [] है jvm_opts में लेबल को बड़ा करने के लिए, उपलब्ध टूल के लेबल.
turbine_data	लेबल की सूची; डिफ़ॉल्ट [] है टर्बाइन_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
turbine_jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] turbine को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
xlint	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] डिफ़ॉल्ट सूची में जोड़ने या हटाने के लिए चेतावनी की सूची. इसे हटाने के लिए, इसके पहले डैश लगाएं. ज़्यादा जानकारी के लिए, -Xlint विकल्पों के बारे में Javac दस्तावेज़ देखें.