Java के नियम

7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

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: सोर्स वाला संग्रह ("सोर्स जार").
  • name_deploy.jar: डिप्लॉयमेंट के लिए सही Java संग्रह (सिर्फ़ साफ़ तौर पर अनुरोध किए जाने पर बनाया जाता है).

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

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

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

  • 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 टाइप की सोर्स फ़ाइलों को पैक नहीं किया जाता और कंपाइल किया जाता है. (यह तरीका तब काम आता है, जब आपको जेनरूल वाली .java फ़ाइलों का सेट जनरेट करने की ज़रूरत हो.)

नियम: अगर कोई नियम (आम तौर पर genrule या filegroup) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए बताया गया है.

यह आर्ग्युमेंट करीब-करीब हमेशा ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपाथ पर क्लास के बारे में बताता हो या आप runtime_deps आर्ग्युमेंट के बारे में बताते हों.

resources

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

Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची.

अगर संसाधनों के बारे में बताया गया, तो उन्हें कंपाइलेशन के ज़रिए बनाई गई सामान्य .class फ़ाइलों के साथ जार में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद एक "resources" डायरेक्ट्री ग्रैंडचाइल्ड) को खोजता है. अगर वह डायरेक्ट्री नहीं मिलती है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई रिसॉर्स <workspace root>/x/java/y/java/z में है, तो रिसॉर्स का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है.

संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.

classpath_resources

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

इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई दूसरा विकल्प न हो)

उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का सिर्फ़ एक मकसद है, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना जिनके रिसॉर्स को क्लासपाथ पर "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) और "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है.

Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा (सभी डिपेंडेंट जार ढूंढने के लिए) शामिल है और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, "$@" होता है, ताकि आप क्लासनाम के बाद दूसरे आर्ग्युमेंट को पास कर सकें. हालांकि, JVM से पार्स करने के लिए बनाए गए आर्ग्युमेंट, कमांड लाइन में क्लास नेम से पहले तय किए जाने चाहिए. क्लास का नाम सूची में शामिल करने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है.

ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
launcher

लेबल; डिफ़ॉल्ट None है

JDK के साथ शामिल सामान्य bin/java प्रोग्राम के बजाय, एक ऐसी बाइनरी बनाएं जिसका इस्तेमाल आपके Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट cc_binary होना चाहिए. Java इनवोकेशन एपीआई को लागू करने वाले किसी भी cc_binary को इस एट्रिब्यूट की वैल्यू के तौर पर सेट किया जा सकता है.

डिफ़ॉल्ट रूप से, Basel सामान्य 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 की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये इनकी तरह नहीं दिखेंगे, कंपाइल के समय क्लासपाथ पर नहीं. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी विश्लेषण टूल को उन टारगेट पर ध्यान नहीं देना चाहिए जो 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 फ़ाइलों की सूची.

बूलियन; डिफ़ॉल्ट 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 एट्रिब्यूट में मौजूद टारगेट को रनफ़ाइल में शामिल किया जाता है. हालांकि, ये न तो कंपाइल-टाइम और न ही रनटाइम क्लासपाथ पर शामिल किए जाते हैं.

srcs

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

टारगेट बनाने के लिए प्रोसेस की जाने वाली सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है.

.java टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई .java फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ना आसान हो जाता है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम बेहतर हो जाता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह की जानकारी ठीक करनी होगी: जनरेट करने वाले नियम का outs. आपको deps में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम नहीं करता.

.srcjar टाइप की सोर्स फ़ाइलों को पैक नहीं किया जाता और कंपाइल किया जाता है. (यह तरीका तब काम आता है, जब आपको जेनरूल वाली .java फ़ाइलों का सेट जनरेट करने की ज़रूरत हो.)

नियम: अगर कोई नियम (आम तौर पर genrule या filegroup) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए बताया गया है.

यह आर्ग्युमेंट ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपथ पर किसी क्लास की जानकारी देता है या आपने runtime_deps आर्ग्युमेंट दिया है, तो यह ज़रूरी नहीं है.

data

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

रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाकर data के बारे में सामान्य टिप्पणियां देखें.

java_library बनाते समय, Baze इन फ़ाइलों को कहीं भी सेव नहीं करता है; अगर data फ़ाइलें जनरेट की गई हैं, तो Basel उन्हें जनरेट करती है. इस java_library Baze सिस्टम पर आधारित टेस्ट बनाते समय, data फ़ाइलों को रनफ़ाइल एरिया में कॉपी या लिंक किया जाता है.

resources

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

Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची.

अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट होने वाली सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Baze, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह एक "src" डायरेक्ट्री है, जिसके बाद "रिसॉर्स" डायरेक्ट्री होती है. अगर वह डायरेक्ट्री नहीं मिलती है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई रिसॉर्स <workspace root>/x/java/y/java/z में है, तो रिसॉर्स का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है.

संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.

exported_plugins

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

इस लाइब्रेरी पर सीधे तौर पर निर्भर लाइब्रेरी में एक्सपोर्ट करने के लिए, java_plugin (जैसे, जानकारी देने वाले प्रोसेसर) की सूची.

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

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है.

ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.

बूलियन; डिफ़ॉल्ट False है

इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान भी. यह तब काम आता है, जब स्क्रिप्ट चलाने के दौरान रनटाइम एनवायरमेंट की मदद से लाइब्रेरी उपलब्ध कराई जाए. इस तरह की लाइब्रेरी के उदाहरण, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चलने वाले किसी भी वर्शन के लिए tools.jar हैं.

ध्यान दें कि neverlink = 1, कंपाइलर को इस लाइब्रेरी से कॉन्टेंट को कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता है. यह उन कंपाइलेशन टारगेट पर निर्भर करता है जो Java लैंग्वेज स्पेसिफ़िकेशन की अनुमति के हिसाब से, इस पर निर्भर करते हैं (जैसे, static final String के कॉन्स्टेंट या प्राइमटिव टाइप. इसलिए, रनटाइम लाइब्रेरी और कंपाइलेशन लाइब्रेरी एक जैसी होने पर, इसका इस्तेमाल करना बेहतर होता है.

अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग हो जहां JLS ने कंपाइलर को इनलाइन जाने से रोका हो. साथ ही, यह JLS के आने वाले सभी वर्शन के लिए लागू होना चाहिए.

plugins

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

कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में दिया गया हर java_plugin चलाया जाएगा. लाइब्रेरी में उन डिपेंडेंसी से प्लगिन भी इनहेरिट किए जा सकते हैं जो exported_plugins का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के तहत जनरेट किए गए jar में शामिल किए जाएंगे.
proguard_specs

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

ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा. अगर बताया गया है, तो इस लाइब्रेरी के आधार पर उन्हें किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ ऐसे नियम होने चाहिए: -dontnote, -dont Warn, अटैचिंगनोसाइडइफ़ेक्ट, और -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 टाइप की सोर्स फ़ाइलों को पैक नहीं किया जाता और कंपाइल किया जाता है. (यह तरीका तब काम आता है, जब आपको जेनरूल वाली .java फ़ाइलों का सेट जनरेट करने की ज़रूरत हो.)

नियम: अगर नियम (आम तौर पर genrule या filegroup) ऊपर दी गई फ़ाइलों में से किसी को जनरेट करता है, तो उनका इस्तेमाल सोर्स फ़ाइलों के लिए बताए गए तरीके की तरह से ही किया जाएगा.

यह आर्ग्युमेंट ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपथ पर किसी क्लास की जानकारी देता है या आपने runtime_deps आर्ग्युमेंट दिया है, तो यह ज़रूरी नहीं है.

resources

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

Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची.

अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट होने वाली सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Baze, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह एक "src" डायरेक्ट्री है, जिसके बाद "रिसॉर्स" डायरेक्ट्री होती है. अगर वह डायरेक्ट्री नहीं मिलती है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई रिसॉर्स <workspace root>/x/java/y/java/z में है, तो रिसॉर्स का पाथ y/java/z होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, संसाधन फ़ाइलों के लिए कोई खास वैकल्पिक डायरेक्ट्री बताने के लिए, resource_strip_prefix एट्रिब्यूट का इस्तेमाल किया जा सकता है.

संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.

classpath_resources

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

इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई दूसरा विकल्प न हो)

संसाधनों की एक सूची, जो Java ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद सिर्फ़ तीसरे पक्ष की लाइब्रेरी के लिए काम करना है, जिसके लिए ज़रूरी है कि उनके संसाधन, क्लासपाथ पर ठीक "myconfig.xml" के जैसे ही मिलें. नेमस्पेस के विवादों के खतरे की वजह से, इसे सिर्फ़ बाइनरी पर अनुमति होती है, लाइब्रेरी पर नहीं.

create_executable

बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट है True

यह अब काम नहीं करता. इसके बजाय, java_single_jar का इस्तेमाल करें.
deploy_manifest_lines

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची, जो *_deploy.jar टारगेट के लिए जनरेट हुई है. इस एट्रिब्यूट के कॉन्टेंट में, "वैरिएबल बनाएं" विकल्प का इस्तेमाल करके बदलाव नहीं किया जा सकता.
javacopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.

ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.
jvm_flags

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड करने के लिए फ़्लैग की सूची. यह $(location) और "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है.

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 Bazel फ़्लैग का असर सिर्फ़ उन java_binary और java_test टारगेट पर पड़ता है जिनके लिए न launcher एट्रिब्यूट तय किया गया है.

ध्यान दें कि आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी इस हिसाब से अलग-अलग होंगी कि आपने JDK लॉन्चर का इस्तेमाल किया है या किसी दूसरे लॉन्चर का:

  • अगर सामान्य 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 का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधनों को, इस नियम के तहत जनरेट किए गए jar में शामिल किया जाएगा.
resource_jars

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

अब काम नहीं करता: इसके बजाय, java_import और deps या runtime_deps का इस्तेमाल करें.
resource_strip_prefix

स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है

Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स.

अगर यह प्रीफ़िक्स दिया गया है, तो resources एट्रिब्यूट में मौजूद हर फ़ाइल से यह प्रीफ़िक्स हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह पैरामीटर तय नहीं किया गया है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल foo/bar/a.txt पर होगी.

runtime_deps

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

ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. आम deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये रनटाइम क्लास पाथ पर नहीं दिखेंगे, न कि कंपाइल-टाइम क्लासपाथ पर. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी-ऐनालिसिस टूल को उन टारगेट को अनदेखा करना चाहिए जो runtime_deps और deps, दोनों में दिखते हैं.
stamp

पूर्णांक; डिफ़ॉल्ट 0 है

बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है:
  • stamp = 1: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा --nostamp बिल्ड में भी करें. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बिटरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता.
  • stamp = 0: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे बिल्ड के अच्छे नतीजों को कैश मेमोरी में सेव किया जाता है.
  • stamp = -1: बाइल्ड की जानकारी को एम्बेड करने की सुविधा, --[no]stamp फ़्लैग से कंट्रोल की जाती है.

स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो जाए.
test_class

स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है

जांच करने वाले रनर की ओर से लोड की जाने वाली Java क्लास.

डिफ़ॉल्ट रूप से, अगर यह आर्ग्युमेंट सेट नहीं किया गया है, तो लेगसी मोड का इस्तेमाल किया जाता है. साथ ही, उसकी जगह जांच वाले आर्ग्युमेंट इस्तेमाल किए जाते हैं. पहले आर्ग्युमेंट पर, फ़ॉलबैक नहीं करने के लिए, --nolegacy_bazel_java_test फ़्लैग को सेट करें.

इस एट्रिब्यूट से, उस Java क्लास का नाम पता चलता है जिसे इस टेस्ट से चलाया जाना है. इसे सेट करने की ज़रूरत कभी-कभार ही होती है. अगर इस आर्ग्युमेंट को छोड़ दिया जाता है, तो इसे टारगेट के name और उसके सोर्स-रूट-रिलेटिव पाथ का इस्तेमाल करके अनुमान लगाया जाएगा. अगर जांच किसी ऐसे सोर्स रूट के बाहर मौजूद है जिसके बारे में पहले ही जानकारी है, तो test_class के सेट न होने पर Baज़र, गड़बड़ी की सूचना देगा.

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

बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं.

अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े --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 टाइप की सोर्स फ़ाइलों को पैक नहीं किया जाता और कंपाइल किया जाता है. (यह तरीका तब काम आता है, जब आपको जेनरूल वाली .java फ़ाइलों का सेट जनरेट करने की ज़रूरत हो.)

नियम: अगर नियम (आम तौर पर genrule या filegroup) ऊपर दी गई फ़ाइलों में से किसी को जनरेट करता है, तो उनका इस्तेमाल सोर्स फ़ाइलों के लिए बताए गए तरीके की तरह से ही किया जाएगा.

यह आर्ग्युमेंट करीब-करीब हमेशा ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपाथ पर क्लास के बारे में बताता हो या आप runtime_deps आर्ग्युमेंट के बारे में बताते हों.

data

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

रनटाइम के दौरान इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. data के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं.

java_library बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं डालता. अगर data फ़ाइलें जनरेट की गई फ़ाइलें हैं, तो Bazel उन्हें जनरेट करता है. इस java_library पर निर्भर करने वाले किसी जांच को बिल्ड करते समय, Bazel data फ़ाइलों को रनफ़ाइल्स एरिया में कॉपी करता है या लिंक करता है.

resources

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

Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची.

अगर संसाधनों के बारे में बताया गया, तो उन्हें कंपाइलेशन के ज़रिए बनाई गई सामान्य .class फ़ाइलों के साथ जार में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Baze, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह एक "src" डायरेक्ट्री है, जिसके बाद "रिसॉर्स" डायरेक्ट्री होती है. अगर वह डायरेक्ट्री नहीं मिलती है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई रिसॉर्स <workspace root>/x/java/y/java/z में है, तो रिसॉर्स का पाथ y/java/z होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, संसाधन फ़ाइलों के लिए कोई खास वैकल्पिक डायरेक्ट्री बताने के लिए, resource_strip_prefix एट्रिब्यूट का इस्तेमाल किया जा सकता है.

रिसॉर्स, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.

generates_api

बूलियन; डिफ़ॉल्ट तौर पर False

यह एट्रिब्यूट, एपीआई कोड जनरेट करने वाले एनोटेशन प्रोसेसर को मार्क करता है.

अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो उस पर निर्भर अन्य नियम, जनरेट किए गए कोड का रेफ़रंस सिर्फ़ तब दे सकते हैं, जब उनके कोड को इकट्ठा करने की कार्रवाइयां, जनरेट करने वाले नियम के बाद शेड्यूल की गई हों. यह एट्रिब्यूट, --java_header_compilation चालू होने पर, शेड्यूलिंग की पाबंदियां लागू करने के लिए Bazel को निर्देश देता है.

चेतावनी: इस एट्रिब्यूट से बिल्ड की परफ़ॉर्मेंस पर असर पड़ता है. इसलिए, इसका इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर करें.
javacopts

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से.

ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.

बूलियन; डिफ़ॉल्ट False है

इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान भी. यह तब काम आता है, जब स्क्रिप्ट चलाने के दौरान रनटाइम एनवायरमेंट की मदद से लाइब्रेरी उपलब्ध कराई जाए. इस तरह की लाइब्रेरी के उदाहरण, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चलने वाले किसी भी वर्शन के लिए tools.jar हैं.

ध्यान दें कि neverlink = 1, कंपाइलर को इस लाइब्रेरी से कॉन्टेंट को कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता है. यह उन कंपाइलेशन टारगेट पर निर्भर करता है जो Java लैंग्वेज स्पेसिफ़िकेशन की अनुमति के हिसाब से, इस पर निर्भर करते हैं (जैसे, 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, -dont Warn, अटैचिंगनोसाइडइफ़ेक्ट, और -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 टारगेट के लिए हर्मेटिक चालू होता है और टारगेट classlist एट्रिब्यूट की जानकारी देकर अपना खुद का CDS संग्रह उपलब्ध नहीं कराता है, तो java_runtime डिफ़ॉल्ट CDS को हर्मेटिक डिप्लॉयमेंट जेएआर में पैकेज किया जाता है.
hermetic_srcs

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

रनटाइम में मौजूद फ़ाइलें, जो पूरी तरह से सुरक्षित डिप्लॉयमेंट के लिए ज़रूरी हैं.
java

लेबल; डिफ़ॉल्ट None है

Java की एक्ज़ीक्यूटेबल फ़ाइल का पाथ.
java_home

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

रनटाइम के रूट का पाथ. "Make" वैरिएबल के बदले इस्तेमाल किया जा सकता है. अगर यह पाथ ऐब्सलूट वाला है, तो यह नियम एक ऐसे पाथ के साथ-साथ नॉन-हर्मेटिक JavaScript रनटाइम दिखाता है जिसके लिए जाना-पहचाना पाथ है. ऐसे में, srcs और java एट्रिब्यूट खाली होने चाहिए.
lib_ct_sym

लेबल; डिफ़ॉल्ट None है

--release के साथ कंपाइलेशन के लिए lib/ct.sim फ़ाइल की ज़रूरत है. अगर इसके बारे में नहीं बताया गया है और 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 लिंट रनर है, तो उसका लेबल.
bootclasspath

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

Java टारगेट बूटक्लासपाथ एंट्री. javac के -bootclasspath फ़्लैग के मुताबिक.
deps_checker

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

ImportDepsChecker डिप्लॉयमेंट का लेबल जार.
forcibly_disable_header_compilation

बूलियन; डिफ़ॉल्ट False है

--java_header_compilation को बदल देता है, ताकि उन प्लैटफ़ॉर्म पर हेडर कंपाइलेशन को बंद किया जा सके जो इसके साथ काम नहीं करते हैं, जैसे कि JDK 7 Bagel.
genclass

लेबल की सूची; ज़रूरी है

GenClass का लेबल डिप्लॉय जार.
header_compiler

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

हेडर कंपाइलर का लेबल. --java_header_compilation चालू होने पर ज़रूरी है.
header_compiler_direct

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

हेडर कंपाइलर का वैकल्पिक लेबल, जिसका इस्तेमाल डायरेक्ट क्लासपाथ कार्रवाइयों के लिए किया जाता है. इनमें एपीआई जनरेट करने वाला एनोटेशन प्रोसेसर शामिल नहीं होता.

यह टूल, एनोटेशन प्रोसेस करने की सुविधा नहीं देता है.

ijar

लेबल की सूची; ज़रूरी है

ijar एक्सीक्यूटेबल का लेबल.
jacocorunner

लेबल; डिफ़ॉल्ट None है

JacocoCoverageRunner डिप्लॉय किए गए jar का लेबल.
java_runtime

लेबल; ज़रूरी है

इस टूलचेन का इस्तेमाल करने के लिए java_runtime. यह एक्ज़ीक्यूशन कॉन्फ़िगरेशन में डिफ़ॉल्ट रूप से java_runtime की वैल्यू पर सेट होता है.
javabuilder

लेबल की सूची; ज़रूरी है

Javaबिल्डर डिप्लॉय जार का लेबल.
javabuilder_data

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

java Builder_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 दस्तावेज़ देखें.