Java के नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 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 फ़ाइल शामिल होती है जिस पर बाइनरी निर्भर करती है. रैपर शेल स्क्रिप्ट को चलाते समय, किसी भी खाली न होने वाले 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: सोर्स ("सोर्स 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 नियम में deps एट्रिब्यूट का इस्तेमाल, srcs के बिना नहीं किया जा सकता. ऐसे नियम में, 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" डायरेक्ट्री ग्रैंडचाइल्ड) को खोजता है. अगर वह डायरेक्ट्री नहीं मिलती है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई रिसॉर्स <workspace root>/x/java/y/java/z में है, तो रिसॉर्स का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
classpath_resources	लेबल की सूची; डिफ़ॉल्ट [] है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई दूसरा विकल्प न हो) उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का सिर्फ़ एक मकसद है, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना जिनके रिसॉर्स को क्लासपाथ पर "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	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद 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	पूर्णांक; डिफ़ॉल्ट वैल्यू -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 एपीआई या स्टैंडर्ड 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" डायरेक्ट्री ग्रैंडचाइल्ड) को खोजता है. अगर वह डायरेक्ट्री नहीं मिलती है, तो Bazel "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 jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट होने वाली सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद एक "resources" डायरेक्ट्री ग्रैंडचाइल्ड) को खोजता है. अगर वह डायरेक्ट्री नहीं मिलती है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई रिसॉर्स <workspace root>/x/java/y/java/z में है, तो रिसॉर्स का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
classpath_resources	लेबल की सूची; डिफ़ॉल्ट [] है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई दूसरा विकल्प न हो) उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का सिर्फ़ एक मकसद है, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना जिनके रिसॉर्स को क्लासपाथ पर "myconfig.xml" के तौर पर पाना ज़रूरी है. नेमस्पेस के टकराव की आशंका की वजह से, इसे सिर्फ़ बिनेरी पर इस्तेमाल करने की अनुमति है, न कि लाइब्रेरी पर.
create_executable	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट True है इसका इस्तेमाल बंद कर दिया गया है. इसके बजाय, java_single_jar का इस्तेमाल करें.
deploy_manifest_lines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] *_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में, "वैरिएबल बनाएं" विकल्प का इस्तेमाल करके बदलाव नहीं किया जा सकता.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद 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, Bazel से चलाए जा रहे 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 पर निर्भर रहने वाले किसी जांच को बिल्ड करते समय, Bazel data फ़ाइलों को रनफ़ाइल एरिया में कॉपी करता है या लिंक करता है.
resources	लेबल की सूची; डिफ़ॉल्ट [] है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट होने वाली सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि 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	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "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 या 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 टारगेट के लिए, हेर्मेटिक डिप्लॉय JAR को चालू किया जाता है और टारगेट, classlist एट्रिब्यूट की मदद से अपना सीडीएस संग्रह नहीं देता है, तो java_runtime डिफ़ॉल्ट सीडीएस को हेर्मेटिक डिप्लॉय JAR में पैकेज किया जाता है.
hermetic_srcs	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम में मौजूद फ़ाइलें, जो पूरी तरह से सुरक्षित डिप्लॉयमेंट के लिए ज़रूरी हैं.
java	लेबल; डिफ़ॉल्ट None है Java की एक्ज़ीक्यूट की जा सकने वाली फ़ाइल का पाथ.
java_home	स्ट्रिंग; डिफ़ॉल्ट रूप से "" रनटाइम के रूट का पाथ. "Make" वैरिएबल के बदले इस्तेमाल किया जा सकता है. अगर यह पाथ एब्सोलूट है, तो नियम से पता चलता है कि यह एक ऐसा 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_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 टारगेट के 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	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] JavaBuilder को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
javac_supports_multiplex_workers	बूलियन; डिफ़ॉल्ट तौर पर True अगर JavaBuilder, मल्टीप्लेक्स पर्सिस्टेंट वर्कर्स के तौर पर काम करता है, तो True. अगर नहीं करता है, तो False.
javac_supports_worker_multiplex_sandboxing	बूलियन; डिफ़ॉल्ट तौर पर False अगर 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	लेबल की सूची; डिफ़ॉल्ट [] है turbine_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
turbine_jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] turbine को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
xlint	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] डिफ़ॉल्ट सूची में जोड़ने या हटाने के लिए चेतावनी की सूची. इसे हटाने के लिए, इसके पहले डैश लगाएं. ज़्यादा जानकारी के लिए, -Xlint विकल्पों के बारे में Javac दस्तावेज़ देखें.