Java के नियम

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें नाइटली · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

java_binary

नियम का सोर्स देखें 
java_binary(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, output_licenses, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)

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

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

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

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

java_binary नियम में deps विशेषता के बिना अनुमति नहीं है srcs; इस तरह के नियम के लिए ज़रूरी है main_class इन्होंने दिया runtime_deps.

यह कोड स्निपेट एक सामान्य गलती को दिखाता है:

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 फ़ाइलें. अंदर मौजूद संसाधनों की जगह जार फ़ाइल, प्रोजेक्ट के स्ट्रक्चर के हिसाब से तय होती है. Basel ने सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट, (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री पोता-चाइल्ड) है). अगर ऐसा नहीं है मिल गया, तो इसके बाद बेज़ल "java" नाम की सबसे लोकप्रिय डायरेक्ट्री को खोजता है या "Javatest" (इसलिए, उदाहरण के लिए, अगर कोई संसाधन <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 है

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

डिफ़ॉल्ट रूप से, 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

String; "" डिफ़ॉल्ट है

एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, main() तरीके वाली क्लास का नाम. अगर किसी नियम में इस विकल्प का इस्तेमाल किया जाता है, तो उसके लिए srcs=[...] सूची की ज़रूरत नहीं होती. इसलिए, इस एट्रिब्यूट की मदद से, किसी ऐसी Java लाइब्रेरी से एक्ज़ीक्यूटेबल बनाया जा सकता है जो पहले से ही में एक या ज़्यादा main() विधियां हैं.

इस एट्रिब्यूट की वैल्यू, क्लास का नाम है, न कि सोर्स फ़ाइल. क्लास रनटाइम पर उपलब्ध: इसे इस नियम के ज़रिए (srcs से) कंपाइल किया जा सकता है या डायरेक्ट या ट्रांज़िटिव डिपेंडेंसी से उपलब्ध कराया गया (runtime_deps या deps). अगर क्लास उपलब्ध नहीं है, तो रनटाइम के दौरान बाइनरी फ़ेल हो जाएगी; यह लीजिए समय की जांच नहीं होती है.

plugins

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

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

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

यह सुविधा अब काम नहीं करती: इसके बजाय, java_Import और deps या बनाए गए रनटाइम_deps का इस्तेमाल करें.
resource_strip_prefix

String; "" डिफ़ॉल्ट है

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 डिफ़ॉल्ट है

टेस्ट रनर का इस्तेमाल करें (डिफ़ॉल्ट रूप से) com.google.testing.junit.runner.BazelTestRunner) क्लास के तौर पर Java प्रोग्राम का मुख्य एंट्री पॉइंट और टेस्ट क्लास को टेस्ट रनर को bazel.test_suite की वैल्यू के तौर पर जोड़ें सिस्टम प्रॉपर्टी. आप डिफ़ॉल्ट को ओवरराइड करने के लिए इसका इस्तेमाल कर सकते हैं व्यवहार, जिसमें टेस्ट रनर का इस्तेमाल करना है java_test नियम, और java_binary नियमों के लिए इसका इस्तेमाल न करें. इसकी संभावना नहीं है आपको यह करना है. AllTest के लिए एक बार इस्तेमाल किया जा सकता है ऐसे नियम जिन्हें किसी दूसरे नियम से शुरू किया जाता है (डेटाबेस सेट अप करने के लिए) उदाहरण के लिए,). AllTest नियम का एलान java_binary के तौर पर किया जाना चाहिए, लेकिन के तौर पर अब भी टेस्ट रनर का इस्तेमाल करें. टेस्ट रनर क्लास का नाम, main_class एट्रिब्यूट से बदला जा सकता है.

java_import

नियम का सोर्स देखें 
java_import(name, deps, data, add_exports, add_opens, 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, toolchains, 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 पर जाएं.
data

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

रनटाइम के दौरान इस नियम के तहत ज़रूरी फ़ाइलों की सूची.
add_exports

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

इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें.

यह javac और JVM --add-exports= flags के बराबर है.

add_opens

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

इस लाइब्रेरी को दिए गए module के हिसाब से ऐक्सेस करने की अनुमति दें या package.

यह javac और JVM --add-opens= flags के बराबर है.

constraints

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

Java लाइब्रेरी के तौर पर, इस नियम पर लगाई गई अतिरिक्त पाबंदियां.
exports

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

इस नियम के उपयोगकर्ताओं को उपलब्ध कराने के लिए टारगेट. java_library.exports को देखें.
jars

लेबल की सूची; आवश्यक

इस टारगेट पर आधारित Java टारगेट को दी गई JAR फ़ाइलों की सूची.

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

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

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

ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. यहां ProGuard की ओर से इस्तेमाल की जाने वाली खास जानकारी के बारे में बताया जाएगा. अगर तय किया गया हो, उन्हें इस लाइब्रेरी के आधार पर किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ पहचान बदलने वाले नियम होने चाहिए, जैसे कि -dontnote, -dontvarn, माना जाता है कि -keep से शुरू होने वाले नियम और साइड इफ़ेक्ट शामिल हैं. अन्य विकल्प सिर्फ़ यहां दिख सकते हैं android_binary के ProGuard_specs, ताकि नॉन-टॉटलॉजिकल मर्ज पक्का किए जा सकें.
runtime_deps

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

ऐसी लाइब्रेरी जिन्हें सिर्फ़ रनटाइम के समय पर फ़ाइनल बाइनरी या टेस्ट के लिए उपलब्ध कराया जाना है. java_library.runtime_deps देखें.
srcjar

लेबल; डिफ़ॉल्ट रूप से None है

एक JAR फ़ाइल, जिसमें कंपाइल की गई JAR फ़ाइलों का सोर्स कोड होता है.

java_library

नियम का सोर्स देखें 
java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, 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) जनरेट होता है इनमें से किसी भी फ़ाइल का इस्तेमाल नहीं किया जाएगा, तो उनका इस्तेमाल सोर्स के लिए बताए गए तरीके से ही किया जाएगा फ़ाइलें शामिल हैं.

.properties टाइप की सोर्स फ़ाइलों को संसाधन माना जाता है.

अन्य सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताया गया फ़ाइल टाइप है. ऐसा न करने पर कोई गड़बड़ी मिलेगी.

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

data

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

रनटाइम के दौरान इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. data के बारे में सामान्य टिप्पणियां यहां देखें इनकी ओर से तय की गई सामान्य विशेषताएं ज़्यादातर बिल्ड रूल के तहत आते हैं.

java_library बनाते समय, Basel इन फ़ाइलों को कहीं भी नहीं रखता है; अगर data फ़ाइलें जनरेट की जाती हैं. इसके बाद, Basel उन्हें जनरेट करती है. किसी की जांच करेगा, जो इस पर निर्भर करता है: java_library Baज़र चैनल की कॉपी या लिंक रनफ़ाइल एरिया में data फ़ाइलें.

resources

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

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

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

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

add_exports

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

इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें.

यह javac और JVM --add-exports= flags के बराबर है.

add_opens

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

इस लाइब्रेरी को दिए गए module के हिसाब से ऐक्सेस करने की अनुमति दें या package.

यह javac और JVM --add-opens= flags के बराबर है.

bootclasspath

लेबल; डिफ़ॉल्ट रूप से None है

प्रतिबंधित एपीआई, इस्तेमाल न करें!
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 के लिए (और ऐसी कोई भी चीज़ जो A पर निर्भर हो सकती है) के (B के) exports में C का एलान करके एट्रिब्यूट की वैल्यू सबमिट करें.

एक्सपोर्ट की गई लाइब्रेरी को बंद करने की सुविधा, सीधे तौर पर पैरंट के सभी नियमों के तहत आती है. थोड़ा सा लें कोई दूसरा उदाहरण: A, B पर निर्भर करता है, B C और D पर निर्भर करता है. साथ ही, C को एक्सपोर्ट करता है, लेकिन D को नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अब, अगर C और D ने कुछ लाइब्रेरी एक्सपोर्ट की हैं, तो C' और D' उसी क्रम में, A केवल C' लेकिन D' नहीं.

अहम जानकारी: एक्सपोर्ट किया गया नियम, नियमित डिपेंडेंसी नहीं है. पिछले उदाहरण पर अमल करते हुए, अगर B, C को एक्सपोर्ट करता है और C का भी इस्तेमाल करना चाहता है, तो उसे deps.

javabuilder_jvm_flags

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

प्रतिबंधित एपीआई, इस्तेमाल न करें!
javacopts

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

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

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

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

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

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

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

plugins

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

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

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

ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. यहां ProGuard की ओर से इस्तेमाल की जाने वाली खास जानकारी के बारे में बताया जाएगा. अगर तय किया गया हो, उन्हें इस लाइब्रेरी के आधार पर किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ पहचान बदलने वाले नियम होने चाहिए, जैसे कि -dontnote, -dontvarn, माना जाता है कि -keep से शुरू होने वाले नियम और साइड इफ़ेक्ट शामिल हैं. अन्य विकल्प सिर्फ़ यहां दिख सकते हैं android_binary के ProGuard_specs, ताकि नॉन-टॉटलॉजिकल मर्ज पक्का किए जा सकें.
resource_strip_prefix

String; "" डिफ़ॉल्ट है

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, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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

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

उदाहरण: 


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

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

proto_library(
    name = "bar",
)

तर्क

विशेषताएं
name

नाम; आवश्यक

इस टारगेट के लिए यूनीक नाम.
deps

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

proto_library की सूची नियम तय करते हैं.

java_proto_library

नियम का सोर्स देखें 
java_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

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

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

उदाहरण: 


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

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

proto_library(
    name = "foo_proto",
)

तर्क

विशेषताएं
name

नाम; आवश्यक

इस टारगेट के लिए यूनीक नाम.
deps

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

proto_library की सूची नियम तय करते हैं.

java_test

नियम का सोर्स देखें 
java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, 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, neverlink, plugins, 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 पर क्लिक करें.

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 आर्ग्युमेंट डालें.

data

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

रनटाइम के दौरान इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. data के बारे में सामान्य टिप्पणियां देखें पर सामान्य विशेषताएं ज़्यादातर बिल्ड रूल के तहत आते हैं.
resources

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

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

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

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

add_exports

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

इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें.

यह javac और JVM --add-exports= flags के बराबर है.

add_opens

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

इस लाइब्रेरी को दिए गए module के हिसाब से ऐक्सेस करने की अनुमति दें या package.

यह javac और JVM --add-opens= flags के बराबर है.

bootclasspath

लेबल; डिफ़ॉल्ट रूप से None है

प्रतिबंधित एपीआई, इस्तेमाल न करें!
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 है

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

डिफ़ॉल्ट रूप से, 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

String; "" डिफ़ॉल्ट है

एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, main() तरीके वाली क्लास का नाम. अगर किसी नियम में इस विकल्प का इस्तेमाल किया जाता है, तो उसके लिए srcs=[...] सूची की ज़रूरत नहीं होती. इसलिए, इस एट्रिब्यूट की मदद से, किसी ऐसी Java लाइब्रेरी से एक्ज़ीक्यूटेबल बनाया जा सकता है जो पहले से ही में एक या ज़्यादा main() विधियां हैं.

इस एट्रिब्यूट की वैल्यू, क्लास का नाम है, न कि सोर्स फ़ाइल. क्लास रनटाइम पर उपलब्ध: इसे इस नियम के ज़रिए (srcs से) कंपाइल किया जा सकता है या डायरेक्ट या ट्रांज़िटिव डिपेंडेंसी से उपलब्ध कराया गया (runtime_deps या deps). अगर क्लास उपलब्ध नहीं है, तो रनटाइम के दौरान बाइनरी फ़ेल हो जाएगी; यह लीजिए समय की जांच नहीं होती है.

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

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

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

String; "" डिफ़ॉल्ट है

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

String; "" डिफ़ॉल्ट है

टेस्ट रनर से लोड की जाने वाली Java क्लास.

डिफ़ॉल्ट रूप से, अगर इस आर्ग्युमेंट के बारे में नहीं बताया गया है, तो लेगसी मोड का इस्तेमाल किया जाता है और इसके बजाय, परीक्षण आर्ग्युमेंट का इस्तेमाल किया जाता है. --nolegacy_bazel_java_test फ़्लैग सेट करें शामिल न करें.

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

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 डिफ़ॉल्ट है

टेस्ट रनर का इस्तेमाल करें (डिफ़ॉल्ट रूप से) com.google.testing.junit.runner.BazelTestRunner) क्लास के तौर पर Java प्रोग्राम का मुख्य एंट्री पॉइंट और टेस्ट क्लास को टेस्ट रनर को 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, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, tags, target_compatible_with, testonly, toolchains, 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 कंपाइलर फ़्लैग.
output_licenses

स्ट्रिंग की सूची; [] डिफ़ॉल्ट है
packages

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

package_group का सेट कॉन्फ़िगरेशन को लागू किया जाना चाहिए.

java_plugin

नियम का सोर्स देखें 
java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, 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) जनरेट होता है इनमें से किसी भी फ़ाइल का इस्तेमाल नहीं किया जाएगा, तो उनका इस्तेमाल सोर्स के लिए बताए गए तरीके से ही किया जाएगा फ़ाइलें शामिल हैं.

.properties टाइप की सोर्स फ़ाइलों को संसाधन माना जाता है.

अन्य सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताया गया फ़ाइल टाइप है. ऐसा न करने पर कोई गड़बड़ी मिलेगी.

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

data

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

रनटाइम के दौरान इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. data के बारे में सामान्य टिप्पणियां यहां देखें इनकी ओर से तय की गई सामान्य विशेषताएं ज़्यादातर बिल्ड रूल के तहत आते हैं.

java_library बनाते समय, Basel इन फ़ाइलों को कहीं भी नहीं रखता है; अगर data फ़ाइलें जनरेट की जाती हैं. इसके बाद, Basel उन्हें जनरेट करती है. किसी की जांच करेगा, जो इस पर निर्भर करता है: java_library Baज़र चैनल की कॉपी या लिंक रनफ़ाइल एरिया में data फ़ाइलें.

resources

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

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

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

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

add_exports

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

इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें.

यह javac और JVM --add-exports= flags के बराबर है.

add_opens

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

इस लाइब्रेरी को दिए गए module के हिसाब से ऐक्सेस करने की अनुमति दें या package.

यह javac और JVM --add-opens= flags के बराबर है.

bootclasspath

लेबल; डिफ़ॉल्ट रूप से None है

प्रतिबंधित एपीआई, इस्तेमाल न करें!
generates_api

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

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

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

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

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

प्रतिबंधित एपीआई, इस्तेमाल न करें!
javacopts

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

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

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

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

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

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

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

output_licenses

स्ट्रिंग की सूची; [] डिफ़ॉल्ट है
plugins

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

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

String; "" डिफ़ॉल्ट है

प्रोसेसर क्लास क्लास का पूरी तरह क्वालिफ़ाइड टाइप है, जिसे Java कंपाइलर को चाहिए को एनोटेशन प्रोसेसर के एंट्री पॉइंट के तौर पर इस्तेमाल करें. अगर यह नियम तय नहीं किया गया है, तो Java कंपाइलर की एनोटेशन प्रोसेसिंग में, एक एनोटेशन प्रोसेसर का योगदान देगा, लेकिन रनटाइम क्लासपाथ को अब भी कंपाइलर के एनोटेशन प्रोसेसर पाथ में शामिल किया जाएगा. (यह मुख्य रूप से इसका इस्तेमाल करने के लिए है गड़बड़ी की संभावना वाले प्लगिन, जो लोड होते हैं का इस्तेमाल करके एनोटेशन प्रोसेसर पाथ से java.util.ServiceLoader.)
proguard_specs

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

ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. यहां ProGuard की ओर से इस्तेमाल की जाने वाली खास जानकारी के बारे में बताया जाएगा. अगर तय किया गया हो, उन्हें इस लाइब्रेरी के आधार पर किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ पहचान बदलने वाले नियम होने चाहिए, जैसे कि -dontnote, -dontvarn, माना जाता है कि -keep से शुरू होने वाले नियम और साइड इफ़ेक्ट शामिल हैं. अन्य विकल्प सिर्फ़ यहां दिख सकते हैं android_binary के ProGuard_specs, ताकि नॉन-टॉटलॉजिकल मर्ज पक्का किए जा सकें.
resource_strip_prefix

String; "" डिफ़ॉल्ट है

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, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, 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 एट्रिब्यूट, java_runtime डिफ़ॉल्ट CDS को हर्मेटिक डिप्लॉयमेंट JAR में पैकेज किया जाता है.
hermetic_srcs

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

हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी रनटाइम में फ़ाइलें.
hermetic_static_libs

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

ऐसी लाइब्रेरी जो हर्मेटिक डिप्लॉयमेंट के लिए लॉन्चर से स्टैटिक रूप से लिंक की गई हैं
java

लेबल; डिफ़ॉल्ट रूप से None है

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

String; "" डिफ़ॉल्ट है

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

लेबल; डिफ़ॉल्ट रूप से None है

--release के साथ कंपाइलेशन के लिए lib/ct.sim फ़ाइल की ज़रूरत है. अगर इसके लिए नहीं बताया गया है और srcs में ठीक एक फ़ाइल है जिसका पाथ इसके खत्म होता है /lib/ct.sym, उस फ़ाइल का इस्तेमाल किया जा रहा है.
lib_modules

लेबल; डिफ़ॉल्ट रूप से None है

हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी lib/modules फ़ाइल.
output_licenses

स्ट्रिंग की सूची; [] डिफ़ॉल्ट है
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_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, 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 फ़्लैग के मुताबिक.
compatible_javacopts

null; {} डिफ़ॉल्ट है

इंटरनल एपीआई, इसका इस्तेमाल न करें!
deps_checker

लेबल; डिफ़ॉल्ट रूप से None है

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

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

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

लेबल; डिफ़ॉल्ट रूप से None है

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

लेबल; डिफ़ॉल्ट रूप से None है

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

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

इंटरनल एपीआई, इसका इस्तेमाल न करें!
header_compiler_direct

लेबल; डिफ़ॉल्ट रूप से None है

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

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

ijar

लेबल; डिफ़ॉल्ट रूप से None है

एक्ज़ीक्यूटेबल iJर का लेबल.
jacocorunner

लेबल; डिफ़ॉल्ट रूप से None है

JacocoCoverageRunner का लेबल जार डिप्लॉय करें.
java_runtime

लेबल; डिफ़ॉल्ट रूप से None है

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

लेबल; डिफ़ॉल्ट रूप से None है

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

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

java Builder_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
javabuilder_jvm_opts

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

Javaबिल्डर को शुरू करते समय JVM के लिए आर्ग्युमेंट की सूची.
javac_supports_multiplex_workers

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

अगर Javaबिल्लर, मल्टीप्लेक्स परसिस्टेंट वर्कर के तौर पर चलने की सुविधा देता है, तो सही है. अगर ऐसा नहीं है, तो यह गलत है.
javac_supports_worker_cancellation

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

सही अगर JavaBuilder स्थायी कर्मचारियों को रद्द करने का समर्थन करता है, तो गलत होने पर गलत.
javac_supports_worker_multiplex_sandboxing

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

अगर Javaबिल्लर, सैंडबॉक्सिंग के साथ मल्टीप्लेक्स परसिस्टेंट वर्कर के तौर पर चलने की सुविधा देता है, तो यह 'सही' है. अगर ऐसा नहीं होता है, तो यह 'गलत' है.
javac_supports_workers

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

अगर Javaबिल्लर एक लगातार काम करने वाले (परसिस्टेंट वर्कर) के तौर पर चलने की सुविधा देता है, तो सही है. अगर ऐसा नहीं होता है, तो यह गलत होता है.
javacopts

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

Java कंपाइलर के लिए अतिरिक्त आर्ग्युमेंट की सूची. कृपया Java कंपाइलर देखें संभावित Java कंपाइलर फ़्लैग की पूरी सूची के लिए दस्तावेज़.
jspecify_implicit_deps

लेबल; डिफ़ॉल्ट रूप से None है

एक्सपेरिमेंट के तौर पर उपलब्ध है. इसे इस्तेमाल न करें!
jspecify_javacopts

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

एक्सपेरिमेंट के तौर पर उपलब्ध है. इसे इस्तेमाल न करें!
jspecify_packages

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

एक्सपेरिमेंट के तौर पर उपलब्ध है. इसे इस्तेमाल न करें!
jspecify_processor

लेबल; डिफ़ॉल्ट रूप से None है

एक्सपेरिमेंट के तौर पर उपलब्ध है. इसे इस्तेमाल न करें!
jspecify_processor_class

String; "" डिफ़ॉल्ट है

एक्सपेरिमेंट के तौर पर उपलब्ध है. इसे इस्तेमाल न करें!
jspecify_stubs

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

एक्सपेरिमेंट के तौर पर उपलब्ध है. इसे इस्तेमाल न करें!
jvm_opts

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

Java कंपाइलर शुरू करते समय, JVM के आर्ग्युमेंट की सूची. कृपया Java का इस्तेमाल करके इस विकल्प के लिए संभावित फ़्लैग की पूरी सूची के लिए वर्चुअल मशीन दस्तावेज़.
misc

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

बहिष्कृत: इसके बजाय javacopts का उपयोग करें
oneversion

लेबल; डिफ़ॉल्ट रूप से None है

एक वर्शन लागू करने पर लागू होने वाली बाइनरी का लेबल.
oneversion_allowlist_for_tests

लेबल; डिफ़ॉल्ट रूप से None है

टेस्ट के लिए, एक वर्शन की अनुमति वाली सूची का लेबल.
oneversion_whitelist

लेबल; डिफ़ॉल्ट रूप से None है

एक वर्शन की अनुमति वाली सूची का लेबल.
package_configuration

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

ऐसा कॉन्फ़िगरेशन जो बताए गए पैकेज ग्रुप पर लागू होना चाहिए.
proguard_allowlister

लेबल; डिफ़ॉल्ट रूप से "@bazel_tools//tools/jdk:proguard_whitelister" है

ProGuard को अनुमति देने वाले व्यक्ति या कंपनी का लेबल.
reduced_classpath_incompatible_processors

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

इंटरनल एपीआई, इसका इस्तेमाल न करें!
singlejar

लेबल; डिफ़ॉल्ट रूप से None है

SingleJar डिप्लॉय जार का लेबल.
source_version

String; "" डिफ़ॉल्ट है

Java का सोर्स वर्शन (उदाहरण, '6' या '7'). यह कोड स्ट्रक्चर का सेट तय करता है को Java सोर्स कोड में अनुमति दी जाती है.
target_version

String; "" डिफ़ॉल्ट है

Java का टारगेट वर्शन (उदाहरण, '6' या '7'). इससे तय होता है कि क्लास किस Java रनटाइम के लिए है का निर्माण करना चाहिए.
timezone_data

लेबल; डिफ़ॉल्ट रूप से None है

टाइमज़ोन डेटा वाले संसाधन जार का लेबल. अगर यह नीति सेट की जाती है, तो टाइमज़ोन डेटा को सभी java_binary नियमों की इंप्लिसिट रनटाइम डिपेंडेंसी.
tools

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

jvm_opts में लेबल को बड़ा करने के लिए, उपलब्ध टूल के लेबल.
turbine_data

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

टर्बाइन_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
turbine_jvm_opts

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

टर्बाइन को शुरू करते समय JVM के लिए आर्ग्युमेंट की सूची.
xlint

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

डिफ़ॉल्ट सूची में जोड़ने या उससे हटाने के लिए चेतावनी की सूची. इससे पहले दाईं ओर एक डैश लगाकर उसे हटा देता है. ज़्यादा जानकारी के लिए, कृपया -Xlint विकल्पों पर Javac दस्तावेज़ देखें.