Java के नियम

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

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

नियम

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

java_binary

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

java_binary(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, output_licenses, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)

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

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

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

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

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

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

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

• name_deploy-src.jar: यह एक ऐसा संग्रह है जिसमें टारगेट के ट्रांज़िटिव क्लोज़र से इकट्ठा किए गए सोर्स शामिल होते हैं. ये deploy.jar में मौजूद क्लास से मेल खाएंगे. हालांकि, ऐसा सिर्फ़ तब होगा, जब जार का कोई मेल खाने वाला सोर्स जार न हो.

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

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

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

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

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

तर्क

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

java_import

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

java_import(name, deps, data, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, visibility)

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

उदाहरण

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

तर्क

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

java_library

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

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

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

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

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

तर्क

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

java_lite_proto_library

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

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

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

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

उदाहरण:

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

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

proto_library(
    name = "bar",
)

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है proto_library नियमों की सूची, जिनके लिए Java कोड जनरेट करना है.

java_proto_library

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

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

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

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

उदाहरण:

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

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

proto_library(
    name = "foo_proto",
)

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट वैल्यू [] है proto_library नियमों की सूची, जिनके लिए Java कोड जनरेट करना है.

java_test

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

java_test(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)

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

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

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

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

उदाहरण

java_library(
    name = "tests",
    srcs = glob(["*.java"]),
    deps = [
        "//java/com/foo/base:testResources",
        "//java/com/foo/testing/util",
    ],
)

java_test(
    name = "AllTests",
    size = "small",
    runtime_deps = [
        ":tests",
        "//util/mysql",
    ],
)

तर्क

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

java_package_configuration

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

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

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

उदाहरण:

java_package_configuration(
    name = "my_configuration",
    packages = [":my_packages"],
    javacopts = ["-Werror"],
)

package_group(
    name = "my_packages",
    packages = [
        "//com/my/project/...",
        "-//com/my/project/testing/...",
    ],
)

java_toolchain(
    ...,
    package_configuration = [
        ":my_configuration",
    ]
)

तर्क

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

java_plugin

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

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

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

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

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

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

तर्क

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

java_runtime

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

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

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

उदाहरण:

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

तर्क

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

java_toolchain

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

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

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

उदाहरण

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

java_toolchain(
    name = "toolchain",
    source_version = "7",
    target_version = "7",
    bootclasspath = ["//tools/jdk:bootclasspath"],
    xlint = [ "classfile", "divzero", "empty", "options", "path" ],
    javacopts = [ "-g" ],
    javabuilder = ":JavaBuilder_deploy.jar",
)

तर्क

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