Java के नियम

समस्या की शिकायत करें सोर्स देखें

नियम

• java_binary
• java_import
• java_library
• java_lite_proto_library
• java_proto_library
• java_test
• java_package_configuration
• java_plugin
• java_runtime
• java_toolchain

java_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 संग्रह ("जार फ़ाइल") बनाता है. साथ ही, यह नियम वाले नाम से रैपर शेल स्क्रिप्ट बनाता है. रैपर शेल स्क्रिप्ट ऐसे क्लासपाथ का इस्तेमाल करती है जिसमें दूसरी चीज़ों के साथ-साथ, हर उस लाइब्रेरी के लिए एक जार फ़ाइल भी शामिल होती है जिस पर बाइनरी निर्भर करती है. रैपर शेल स्क्रिप्ट चलाते समय, बेज़ेल के --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 टारगेट बनाने पर, मेनिफ़ेस्ट के साथ एक जार फ़ाइल अपने-आप बनी रहती है. इससे इसे java -jar निर्देश या रैपर स्क्रिप्ट के --singlejar विकल्प का इस्तेमाल करके चलाया जा सकता है. रैपर स्क्रिप्ट का इस्तेमाल करने को java -jar पसंद किया जाता है, क्योंकि यह जेवीएम फ़्लैग और नेटिव लाइब्रेरी को लोड करने के विकल्पों को भी पास करता है.

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

  अगर आपका टारगेट किसी लॉन्चर एट्रिब्यूट के बारे में बताता है, तो एक सामान्य JAR फ़ाइल होने के बजाय, _deploy.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 जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर संसाधनों के बारे में बताया गया, तो उन्हें कंपाइलेशन के ज़रिए बनाई गई सामान्य .class फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल के अंदर मौजूद रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर के हिसाब से तय होती है. Baज़ल, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह "src" डायरेक्ट्री के बाद, "रिसॉर्स" डायरेक्ट्री होता है. अगर वह नहीं मिलता है, तो Ba बैंक, "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री को खोजता है. उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, संसाधन फ़ाइलों के लिए कोई खास वैकल्पिक डायरेक्ट्री बताने के लिए, resource_strip_prefix एट्रिब्यूट का इस्तेमाल किया जा सकता है. रिसॉर्स, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
classpath_resources	लेबल की सूची; डिफ़ॉल्ट [] है अगर आपके पास कोई और तरीका नहीं है, तो इस विकल्प का इस्तेमाल न करें) संसाधनों की एक सूची, जो Java ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद सिर्फ़ तीसरे पक्ष की लाइब्रेरी के लिए काम करना है, जिसके लिए ज़रूरी है कि उनके संसाधन, क्लासपाथ पर ठीक "myconfig.xml" के जैसे ही मिलें. नेमस्पेस के विवादों के खतरे की वजह से, इसे सिर्फ़ बाइनरी पर अनुमति होती है, लाइब्रेरी पर नहीं.
create_executable	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट है True यह अब काम नहीं करता. इसके बजाय, java_single_jar का इस्तेमाल करें.
deploy_env	लेबल की सूची; डिफ़ॉल्ट [] है ऐसे अन्य java_binary टारगेट की सूची जो इस बाइनरी के लिए डिप्लॉयमेंट एनवायरमेंट दिखाते हैं. यह एट्रिब्यूट, ऐसा प्लग इन बनाते समय सेट करें जिसे किसी दूसरे java_binary से लोड किया जाएगा. इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉय जार) की वे सभी डिपेंडेंसी शामिल नहीं होती हैं जो इस बाइनरी और deploy_env में तय किए गए टारगेट के बीच शेयर की जाती हैं.
deploy_manifest_lines	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची, जो *_deploy.jar टारगेट के लिए जनरेट हुई है. इस एट्रिब्यूट के कॉन्टेंट की जगह नहीं है, पर "वैरिएबल बनाएं" की जगह लागू होगी.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.
jvm_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड करने के लिए फ़्लैग की सूची. यह $(location) और "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा (सभी डिपेंडेंट जार ढूंढने के लिए) शामिल है और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, "$@" होता है, ताकि आप क्लासनाम के बाद दूसरे आर्ग्युमेंट को पास कर सकें. हालांकि, JVM से पार्स करने के लिए बनाए गए आर्ग्युमेंट, कमांड लाइन में क्लास नेम से पहले तय किए जाने चाहिए. क्लास का नाम सूची में शामिल करने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
launcher	लेबल; डिफ़ॉल्ट None है JDK के साथ शामिल सामान्य bin/java प्रोग्राम के बजाय, एक ऐसी बाइनरी बनाएं जिसका इस्तेमाल आपके Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट cc_binary होना चाहिए. Java इनवोकेशन एपीआई को लागू करने वाले किसी भी cc_binary को इस एट्रिब्यूट की वैल्यू के तौर पर सेट किया जा सकता है. डिफ़ॉल्ट रूप से, Basel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़े --java_launcher बेज़ल फ़्लैग का असर सिर्फ़ उन 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 का इस्तेमाल करती हैं. प्लगिन से जनरेट किए गए रिसॉर्स को, इस नियम के नतीजे में मिलने वाले जार में शामिल किया जाएगा.
resource_jars	लेबल की सूची; डिफ़ॉल्ट [] है यह सुविधा अब काम नहीं करती: इसके बजाय, java_Import और deps या बनाए गए रनटाइम_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 है बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े --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)

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

उदाहरण

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

तर्क

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

java_library

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी में लिंक करने के लिए लाइब्रेरी की सूची. ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाकर, deps के बारे में सामान्य टिप्पणियां देखें. deps में दिए गए java_library नियमों के मुताबिक बनाए गए जार इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके deps, runtime_deps, और exports का ट्रांज़िटिव बंद होना, रनटाइम क्लासपाथ पर रहेगा. इसके उलट, data एट्रिब्यूट में मौजूद टारगेट को रनफ़ाइल में शामिल किया जाता है. हालांकि, ये न तो कंपाइल-टाइम और न ही रनटाइम क्लासपाथ पर शामिल किए जाते हैं.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की जाने वाली सोर्स फ़ाइलों की सूची. यह एट्रिब्यूट आम तौर पर ज़रूरी होता है. नीचे दिए गए अपवाद देखें. .java टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई .java फ़ाइलों के मामले में, आम तौर पर फ़ाइल के नाम के बजाय जनरेट करने के नियम का नाम यहां डाला जाना चाहिए. इससे न सिर्फ़ नियम को पढ़ना आसान हो जाता है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम बेहतर हो जाता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह की जानकारी ठीक करनी होगी: जनरेट करने वाले नियम का outs. आपको जनरेट करने के नियम को deps में शामिल नहीं करना चाहिए, क्योंकि यह नो-ऑप है. .srcjar टाइप की सोर्स फ़ाइलों को पैक नहीं किया जाता और कंपाइल किया जाता है. (यह तरीका तब काम आता है, जब आपको जेनरूल वाली .java फ़ाइलों का सेट जनरेट करने की ज़रूरत हो.) नियम: अगर नियम (आम तौर पर genrule या filegroup) ऊपर दी गई फ़ाइलों में से किसी को जनरेट करता है, तो उनका इस्तेमाल सोर्स फ़ाइलों के लिए बताए गए तरीके की तरह से ही किया जाएगा. यह आर्ग्युमेंट करीब-करीब हमेशा ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपाथ पर क्लास के बारे में बताता हो या आप runtime_deps आर्ग्युमेंट के बारे में बताते हों.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाकर, data के बारे में सामान्य टिप्पणियां देखें. java_library बनाते समय, Baze इन फ़ाइलों को कहीं भी सेव नहीं करता है. अगर data फ़ाइलें जनरेट की गई हैं, तो Basel उन्हें जनरेट करती है. इस java_library Basel पर आधारित टेस्ट बनाते समय, data फ़ाइलों को रनफ़ाइल एरिया में कॉपी या लिंक किया जाता है.
resources	लेबल की सूची; डिफ़ॉल्ट [] है Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर संसाधनों के बारे में बताया गया, तो उन्हें कंपाइलेशन के ज़रिए बनाई गई सामान्य .class फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल के अंदर मौजूद रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर के हिसाब से तय होती है. Baज़ल, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह "src" डायरेक्ट्री के बाद, "रिसॉर्स" डायरेक्ट्री होता है. अगर वह नहीं मिलता है, तो Ba बैंक, "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, A के लिए (B के) exports एट्रिब्यूट में C का एलान करके, A के लिए काम करना आसान बना सकता है. साथ ही, वह ऐसी चीज़ भी जो A पर निर्भर हो सकता है, उसे आसान बना सकता है. एक्सपोर्ट की गई लाइब्रेरी को बंद करने की सुविधा, सीधे तौर पर पैरंट के सभी नियमों के तहत आती है. थोड़ा अलग उदाहरण लें: A, B पर, B, C और D पर निर्भर करता है, और C को एक्सपोर्ट भी करता है, लेकिन D पर नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अब, अगर C और D ने कुछ लाइब्रेरी C' और D को एक्सपोर्ट किया है, तो A को सिर्फ़ C' का ऐक्सेस मिलेगा, D को नहीं. अहम जानकारी: एक्सपोर्ट किया गया नियम, नियमित डिपेंडेंसी नहीं है. पिछले उदाहरण की तरह ही, अगर B को एक्सपोर्ट करना है और वह C का भी इस्तेमाल करना चाहता है, तो उसे भी उसे अपने deps में शामिल करना होगा.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.
neverlink	बूलियन; डिफ़ॉल्ट False है इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान नहीं. यह तब काम आता है, जब स्क्रिप्ट चलाने के दौरान रनटाइम एनवायरमेंट की मदद से लाइब्रेरी उपलब्ध कराई जाए. इस तरह की लाइब्रेरी के उदाहरण, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चलने वाले किसी भी वर्शन के लिए tools.jar हैं. ध्यान दें कि neverlink = 1, कंपाइलर को इस लाइब्रेरी से कॉन्टेंट को कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता है. यह उन कंपाइलेशन टारगेट पर निर्भर करता है जो Java लैंग्वेज स्पेसिफ़िकेशन की अनुमति के हिसाब से, इस पर निर्भर करते हैं (जैसे, String या प्रिमिटिव टाइप के static final कॉन्सटेंट). इसलिए, इस्तेमाल का उदाहरण तब माना जाता है, जब रनटाइम लाइब्रेरी और कंपाइलेशन लाइब्रेरी एक जैसी हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग हो जहां JLS ने कंपाइलर को इनलाइन जाने से रोका हो. साथ ही, यह JLS के आने वाले सभी वर्शन के लिए लागू होना चाहिए.
plugins	लेबल की सूची; डिफ़ॉल्ट [] है कंपाइलर के समय चलाए जाने वाले Java कंपाइलर प्लगिन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में दिया गया हर java_plugin चलाया जाएगा. लाइब्रेरी में उन डिपेंडेंसी से प्लगिन भी इनहेरिट किए जा सकते हैं जो exported_plugins का इस्तेमाल करती हैं. प्लगिन से जनरेट किए गए रिसॉर्स को, इस नियम के नतीजे में मिलने वाले जार में शामिल किया जाएगा.
proguard_specs	लेबल की सूची; डिफ़ॉल्ट [] है ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. यहां ProGuard की ओर से इस्तेमाल की जाने वाली खास जानकारी के बारे में बताया जाएगा. अगर बताया गया है, तो इस लाइब्रेरी के आधार पर उन्हें किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ ऐसे नियम होने चाहिए: -dontnote, -dontwarn, अटैचिंगनोसाइडइफ़ेक्ट, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ android_binary के ProGuard_specs में दिखाए जा सकते हैं, ताकि यह पक्का किया जा सके कि वे ऑटोलॉजिकल तरीके से मर्ज न किए गए हों.
resource_jars	लेबल की सूची; डिफ़ॉल्ट [] है यह सुविधा अब काम नहीं करती: इसके बजाय, java_Import और deps या बनाए गए रनटाइम_deps का इस्तेमाल करें.
resource_strip_prefix	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है Java संसाधनों से स्ट्रिप करने के लिए पाथ प्रीफ़िक्स. अगर बताया गया है, तो resources एट्रिब्यूट में मौजूद हर फ़ाइल से इस पाथ प्रीफ़िक्स को हटा दिया जाता है. किसी संसाधन फ़ाइल को इस डायरेक्ट्री के अंदर न होने की एक गड़बड़ी होती है. अगर इसके बारे में जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ उसी लॉजिक के हिसाब से तय किया जाता है जिस लॉजिक के हिसाब से सोर्स फ़ाइलों का Java पैकेज तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल foo/bar/a.txt पर होगी.
runtime_deps	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी लाइब्रेरी जिन्हें सिर्फ़ रनटाइम के समय पर फ़ाइनल बाइनरी या टेस्ट के लिए उपलब्ध कराया जाना है. सामान्य deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन इनकी तरह नहीं होंगे, न कि कंपाइल-टाइम क्लासपाथ पर. सिर्फ़ रनटाइम के समय ज़रूरी डिपेंडेंसी की जानकारी यहां दी जानी चाहिए. डिपेंडेंसी विश्लेषण टूल को उन टारगेट पर ध्यान नहीं देना चाहिए जो runtime_deps और deps, दोनों में दिखते हैं.

java_lite_proto_library

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

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

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

deps फ़ंक्शन, proto_library के नियमों पर ले जाने वाला होना चाहिए.

उदाहरण:

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

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

proto_library(
    name = "bar",
)

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है 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	लेबल की सूची; डिफ़ॉल्ट [] है 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 जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर संसाधनों के बारे में बताया गया, तो उन्हें कंपाइलेशन के ज़रिए बनाई गई सामान्य .class फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल के अंदर मौजूद रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर के हिसाब से तय होती है. Baज़ल, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह "src" डायरेक्ट्री के बाद, "रिसॉर्स" डायरेक्ट्री होता है. अगर वह नहीं मिलता है, तो Ba बैंक, "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री को खोजता है. उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, संसाधन फ़ाइलों के लिए कोई खास वैकल्पिक डायरेक्ट्री बताने के लिए, resource_strip_prefix एट्रिब्यूट का इस्तेमाल किया जा सकता है. रिसॉर्स, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
classpath_resources	लेबल की सूची; डिफ़ॉल्ट [] है अगर आपके पास कोई और तरीका नहीं है, तो इस विकल्प का इस्तेमाल न करें) संसाधनों की एक सूची, जो Java ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद सिर्फ़ तीसरे पक्ष की लाइब्रेरी के लिए काम करना है, जिसके लिए ज़रूरी है कि उनके संसाधन, क्लासपाथ पर ठीक "myconfig.xml" के जैसे ही मिलें. नेमस्पेस के विवादों के खतरे की वजह से, इसे सिर्फ़ बाइनरी पर अनुमति होती है, लाइब्रेरी पर नहीं.
create_executable	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; डिफ़ॉल्ट है True यह अब काम नहीं करता. इसके बजाय, java_single_jar का इस्तेमाल करें.
deploy_manifest_lines	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची, जो *_deploy.jar टारगेट के लिए जनरेट हुई है. इस एट्रिब्यूट के कॉन्टेंट की जगह नहीं है, पर "वैरिएबल बनाएं" की जगह लागू होगी.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.
jvm_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड करने के लिए फ़्लैग की सूची. यह $(location) और "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. 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 एट्रिब्यूट की जानकारी नहीं दी है. ध्यान दें कि आपकी नेटिव (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 का इस्तेमाल करती हैं. प्लगिन से जनरेट किए गए रिसॉर्स को, इस नियम के नतीजे में मिलने वाले जार में शामिल किया जाएगा.
resource_jars	लेबल की सूची; डिफ़ॉल्ट [] है यह सुविधा अब काम नहीं करती: इसके बजाय, java_Import और deps या बनाए गए रनटाइम_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_groups के उस सेट पर कॉन्फ़िगरेशन लागू होना चाहिए.

java_plugin

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

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

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

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

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी में लिंक करने के लिए लाइब्रेरी की सूची. ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाकर, deps के बारे में सामान्य टिप्पणियां देखें. deps में दिए गए java_library नियमों के मुताबिक बनाए गए जार इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके 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 Basel पर आधारित टेस्ट बनाते समय, data फ़ाइलों को रनफ़ाइल एरिया में कॉपी या लिंक किया जाता है.
resources	लेबल की सूची; डिफ़ॉल्ट [] है Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर संसाधनों के बारे में बताया गया, तो उन्हें कंपाइलेशन के ज़रिए बनाई गई सामान्य .class फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल के अंदर मौजूद रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर के हिसाब से तय होती है. Baज़ल, सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह "src" डायरेक्ट्री के बाद, "रिसॉर्स" डायरेक्ट्री होता है. अगर वह नहीं मिलता है, तो Ba बैंक, "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री को खोजता है. उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, संसाधन फ़ाइलों के लिए कोई खास वैकल्पिक डायरेक्ट्री बताने के लिए, resource_strip_prefix एट्रिब्यूट का इस्तेमाल किया जा सकता है. रिसॉर्स, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
generates_api	बूलियन; डिफ़ॉल्ट False है यह एट्रिब्यूट, एपीआई कोड जनरेट करने वाले एनोटेशन प्रोसेसर को मार्क करता है. अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो उस पर निर्भर दूसरे नियम, जनरेट किए गए कोड को सिर्फ़ तब रेफ़र कर सकते हैं, जब उनके कंपाइलेशन ऐक्शन, जनरेट करने वाले नियम के बाद शेड्यूल किए गए हों. --java_header_compilation चालू होने पर, यह एट्रिब्यूट Basel को शेड्यूलिंग कंस्ट्रेंट लागू करने का निर्देश देता है. चेतावनी: इस एट्रिब्यूट से बिल्ड की परफ़ॉर्मेंस पर असर पड़ता है. ज़रूरी होने पर ही इसका इस्तेमाल करें.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह "वैरिएबल बनाएं" विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं.
neverlink	बूलियन; डिफ़ॉल्ट False है इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान नहीं. यह तब काम आता है, जब स्क्रिप्ट चलाने के दौरान रनटाइम एनवायरमेंट की मदद से लाइब्रेरी उपलब्ध कराई जाए. इस तरह की लाइब्रेरी के उदाहरण, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चलने वाले किसी भी वर्शन के लिए tools.jar हैं. ध्यान दें कि neverlink = 1, कंपाइलर को इस लाइब्रेरी से कॉन्टेंट को कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता है. यह उन कंपाइलेशन टारगेट पर निर्भर करता है जो Java लैंग्वेज स्पेसिफ़िकेशन की अनुमति के हिसाब से, इस पर निर्भर करते हैं (जैसे, String या प्रिमिटिव टाइप के static final कॉन्सटेंट). इसलिए, इस्तेमाल का उदाहरण तब माना जाता है, जब रनटाइम लाइब्रेरी और कंपाइलेशन लाइब्रेरी एक जैसी हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग हो जहां 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, अटैचिंगनोसाइडइफ़ेक्ट, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ android_binary के ProGuard_specs में दिखाए जा सकते हैं, ताकि यह पक्का किया जा सके कि वे ऑटोलॉजिकल तरीके से मर्ज न किए गए हों.
resource_jars	लेबल की सूची; डिफ़ॉल्ट [] है यह सुविधा अब काम नहीं करती: इसके बजाय, java_Import और deps या बनाए गए रनटाइम_deps का इस्तेमाल करें.
resource_strip_prefix	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है Java संसाधनों से स्ट्रिप करने के लिए पाथ प्रीफ़िक्स. अगर बताया गया है, तो resources एट्रिब्यूट में मौजूद हर फ़ाइल से इस पाथ प्रीफ़िक्स को हटा दिया जाता है. किसी संसाधन फ़ाइल को इस डायरेक्ट्री के अंदर न होने की एक गड़बड़ी होती है. अगर इसके बारे में जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ उसी लॉजिक के हिसाब से तय किया जाता है जिस लॉजिक के हिसाब से सोर्स फ़ाइलों का Java पैकेज तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल foo/bar/a.txt पर होगी.

java_runtime

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

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

Java रनटाइम के लिए कॉन्फ़िगरेशन के बारे में बताता है.

उदाहरण:

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम में मौजूद सभी फ़ाइलें.
default_cds	लेबल; डिफ़ॉल्ट None है हर्मेटिक java_runtime के लिए डिफ़ॉल्ट CDS संग्रह. जब किसी java_binary टारगेट के लिए हर्मेटिक चालू होता है और टारगेट classlist एट्रिब्यूट की जानकारी देकर अपना खुद का CDS संग्रह उपलब्ध नहीं कराता है, तो java_runtime डिफ़ॉल्ट CDS को हर्मेटिक डिप्लॉयमेंट जेएआर में पैकेज किया जाता है.
hermetic_srcs	लेबल की सूची; डिफ़ॉल्ट [] है हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी रनटाइम में फ़ाइलें.
java	लेबल; डिफ़ॉल्ट None है Java की एक्ज़ीक्यूटेबल फ़ाइल का पाथ.
java_home	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है रनटाइम के रूट का पाथ. "बनाएं" वैरिएबल के विकल्प पर निर्भर करता है. अगर यह पाथ ऐब्सलूट वाला है, तो यह नियम एक ऐसे पाथ के साथ नॉन-हर्मेटिक 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_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 Lit को शुरू करने पर, JVM के आर्ग्युमेंट की सूची.
android_lint_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है Android लिंट के आर्ग्युमेंट की सूची.
android_lint_package_configuration	लेबल की सूची; डिफ़ॉल्ट [] है Android लिंट कॉन्फ़िगरेशन, जिसे बताए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
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	लेबल की सूची; ज़रूरी है एक्ज़ीक्यूटेबल iJर का लेबल.
jacocorunner	लेबल; डिफ़ॉल्ट None है JacocoCoverageRunner का लेबल जार डिप्लॉय करें.
java_runtime	लेबल; ज़रूरी है इस टूलचेन के साथ इस्तेमाल किया जाने वाला java_runtime. प्रोग्राम चलाने के कॉन्फ़िगरेशन में, यह डिफ़ॉल्ट रूप से java_runtime की वैल्यू पर सेट होता है.
javabuilder	लेबल की सूची; ज़रूरी है Javaबिल्डर डिप्लॉय जार का लेबल.
javabuilder_data	लेबल की सूची; डिफ़ॉल्ट [] है java Builder_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
javabuilder_jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है Javaबिल्डर को शुरू करते समय JVM के लिए आर्ग्युमेंट की सूची.
javac_supports_multiplex_workers	बूलियन; डिफ़ॉल्ट True है अगर Javaबिल्लर, मल्टीप्लेक्स परसिस्टेंट वर्कर के तौर पर चलने की सुविधा देता है, तो सही है. अगर ऐसा नहीं है, तो यह गलत है.
javac_supports_workers	बूलियन; डिफ़ॉल्ट True है अगर Javaबिल्लर एक लगातार काम करने वाले (परसिस्टेंट वर्कर) के तौर पर चलने की सुविधा देता है, तो सही है. अगर ऐसा नहीं होता है, तो यह गलत होता है.
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 को अनुमति देने वाले व्यक्ति या कंपनी का लेबल.
resourcejar	लेबल की सूची; डिफ़ॉल्ट [] है एक्ज़ीक्यूटेबल संसाधन जार बिल्डर का लेबल.
singlejar	लेबल की सूची; ज़रूरी है SingleJar डिप्लॉय जार का लेबल.
source_version	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है Java का सोर्स वर्शन (उदाहरण, '6' या '7'). इससे पता चलता है कि Java सोर्स कोड में, कोड स्ट्रक्चर के कौनसे सेट की अनुमति है.
target_version	स्ट्रिंग; डिफ़ॉल्ट तौर पर "" है Java का टारगेट वर्शन (उदाहरण, '6' या '7'). इससे यह तय होता है कि किस Java रनटाइम के लिए क्लास बनाई जानी चाहिए.
timezone_data	लेबल; डिफ़ॉल्ट None है टाइमज़ोन डेटा वाले संसाधन जार का लेबल. अगर यह नीति सेट की जाती है, तो टाइमज़ोन डेटा को सभी java_binary नियमों के लिए साफ़ तौर पर रनटाइम डिपेंडेंसी के तौर पर जोड़ा जाता है.
tools	लेबल की सूची; डिफ़ॉल्ट [] है jvm_opts में लेबल को बड़ा करने के लिए, उपलब्ध टूल के लेबल.
turbine_data	लेबल की सूची; डिफ़ॉल्ट [] है टर्बाइन_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
turbine_jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है टर्बाइन को शुरू करते समय JVM के लिए आर्ग्युमेंट की सूची.
xlint	स्ट्रिंग की सूची; डिफ़ॉल्ट [] है डिफ़ॉल्ट सूची में जोड़ने या उससे हटाने के लिए चेतावनी की सूची. इसे निकालने के लिए इसके आगे एक डैश करता है. ज़्यादा जानकारी के लिए, कृपया -Xlint विकल्पों पर Javac दस्तावेज़ देखें.