Java नियम

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

नियम

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

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

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

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

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

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

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

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

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

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

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

यह करें:

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

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए खास नाम.


उस सोर्स फ़ाइल के नाम का इस्तेमाल करना अच्छा रहता है जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है (एक्सटेंशन को छोटा करके). उदाहरण के लिए, अगर आपके एंट्री पॉइंट को Main.java कहा जाता है, तो आपका नाम Main हो सकता है.
deps

List of labels; optional

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

List of labels; optional

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

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

.srcjar टाइप की सोर्स फ़ाइलें अनपैक की गई हैं और कंपाइल की गई हैं. (यह तब काम आ सकता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.)

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

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

resources

List of labels; optional

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

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

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

classpath_resources

List of labels; optional

इस विकल्प का इस्तेमाल तब तक न करें, जब तक यह किसी और तरीके से न हो)

रिसॉर्स की ऐसी सूची जो जावा ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद, सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी की मदद करना है जिनके लिए ज़रूरी है कि उनके संसाधन, क्लास पाथ पर "myconfig.xml" के तौर पर ढूंढे जाएं. नेमस्पेस की गड़बड़ी की वजह से, यह बदलाव सिर्फ़ बाइनरी फ़ाइलों पर लागू होता है.

create_executable

Boolean; optional; nonconfigurable; default is True

बाइनरी फ़ाइल एक्ज़ीक्यूटेबल है या नहीं. एक्ज़ीक्यूटेबल ऐसी बाइनरी जो ट्रांज़िटिव रनटाइम डिपेंडेंसी को डिप्लॉयमेंट जार में इकट्ठा करती हैं. हालांकि, इसे सीधे एक्ज़ीक्यूट नहीं किया जा सकता. अगर यह विशेषता सेट की जाती है, तो कोई रैपर स्क्रिप्ट नहीं बनाई जाती. अगर launcher या main_class एट्रिब्यूट सेट हैं, तो इसे 0 पर सेट करना एक गड़बड़ी होती है.
deploy_env

List of labels; optional

इस बाइनरी के लिए, डिप्लॉयमेंट एनवायरमेंट को दिखाने वाले अन्य java_binary टारगेट की सूची. इस प्लग इन को सेट करते समय, ऐसा प्लग इन बनाएं जो किसी दूसरे java_binary को लोड करेगा.
इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ और डिप्लॉयमेंट जार से सभी डिपेंडेंसी शामिल नहीं होती हैं. ये बाइनरी, बाइनरी और deploy_env में दिए गए टारगेट के बीच शेयर की जाती हैं.
deploy_manifest_lines

List of strings; optional

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

List of strings; optional

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

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

jvm_flags

List of strings; optional

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

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

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

launcher

Label; optional

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

डिफ़ॉल्ट रूप से, Bazel सामान्य 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; optional

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

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

plugins

List of labels; optional

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

List of labels; optional

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

String; optional

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

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

runtime_deps

List of labels; optional

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

Integer; optional; default is -1

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

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

use_launcher

Boolean; optional; default is True

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

अगर यह एट्रिब्यूट गलत पर सेट है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े --java_launcher फ़्लैग को इस टारगेट के लिए अनदेखा कर दिया जाएगा.

use_testrunner

Boolean; optional; default is False

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

java_Import

नियम का सोर्स देखें
java_import(name, deps, data, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, visibility)

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

उदाहरण

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

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए खास नाम.

deps

List of labels; optional

टारगेट में जोड़ी जाने वाली अन्य लाइब्रेरी की सूची. java_library.deps देखें.
constraints

List of strings; optional; nonconfigurable

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

List of labels; optional

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

List of labels; required

JAR फ़ाइलों की सूची, जो इस टारगेट पर निर्भर करने वाले Java टारगेट को देती हैं.

Boolean; optional; default is False

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

List of labels; optional

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

List of labels; optional

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

Label; optional

यह एक ऐसी 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: सोर्स वाला एक संग्रह ("source java").

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए खास नाम.

deps

List of labels; optional

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

deps में दिए गए java_library नियमों से बनाए गए जार, इस नियम के कंपाइल होने में लगने वाले क्लास पाथ पर होंगे. इसके अलावा, अपने deps, runtime_deps, और exports को ट्रांज़िट समय में बंद कर दिया जाएगा और रनटाइम क्लास पाथ का इस्तेमाल किया जाएगा.

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

srcs

List of labels; optional

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

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

.srcjar टाइप की सोर्स फ़ाइलें अनपैक की गई हैं और कंपाइल की गई हैं. (यह तब काम आ सकता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.)

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

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

data

List of labels; optional

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

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

resources

List of labels; optional

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

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

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

exported_plugins

List of labels; optional

सीधे इस लाइब्रेरी पर निर्भर लाइब्रेरी पर एक्सपोर्ट करने के लिए, java_plugin की ऐसी सूची (जैसे कि एनोटेशन प्रोसेसर) की सूची.

java_plugin की दी गई सूची उस लाइब्रेरी पर लागू की जाएगी जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती है. जैसे कि लाइब्रेरी ने plugins में साफ़ तौर पर इन लेबल के बारे में बताया हो.

exports

List of labels; optional

एक्सपोर्ट की गई लाइब्रेरी.

यहां जोड़े गए नियमों की मदद से माता-पिता के नियम यहां बताए गए हैं, जैसे कि माता-पिता ने खास तौर पर इन नियमों का पालन किया है. यह सामान्य (बिना एक्सपोर्ट किया गया) deps के लिए सही नहीं है.

खास जानकारी: अगर किसी नियम के deps से शुरू होने वाला कोई डिपेंडेंसी पाथ है, तो वह X के निशान से ऐक्सेस हो सकता है. इसके लिए शून्य या ज़्यादा exports किनारों की ज़रूरत होती है. यह बताने के लिए कुछ उदाहरण देखते हैं.

मान लें कि A, B और B, C पर निर्भर करते हैं. इस मामले में C, A की ट्रांज़िटिव डिपेंडेंसी है. इसलिए, C के सोर्स और फिर से बनाए जाने की वजह से सब कुछ सही तरीके से दोबारा बन जाएगा. हालांकि, वह C में कक्षाओं का इस्तेमाल नहीं कर पाएगा. ऐसा करने के लिए, A को अपनी deps का C बताने के साथ-साथ A, A (जो भी हो सकता है) के लिए, C को इसके (B के) exports एट्रिब्यूट में इस्तेमाल करना आसान हो सकता है.

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

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

javacopts

List of strings; optional

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

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

Boolean; optional; default is False

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

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

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

plugins

List of labels; optional

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

List of labels; optional

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

List of labels; optional

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

String; optional

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

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

runtime_deps

List of labels; optional

सिर्फ़ फ़ाइनल रनटाइम पर या टेस्ट के लिए उपलब्ध लाइब्रेरी. सामान्य 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

Name; required

इस टारगेट के लिए खास नाम.

deps

List of labels; optional

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

Name; required

इस टारगेट के लिए खास नाम.

deps

List of labels; optional

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 संग्रह. (अगर अनुरोध साफ़ तौर पर किया गया हो, सिर्फ़ तब बनाया जाता है.) ज़्यादा जानकारी के लिए, 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

Name; required

इस टारगेट के लिए खास नाम.

deps

List of labels; optional

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

List of labels; optional

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

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

.srcjar टाइप की सोर्स फ़ाइलें अनपैक की गई हैं और कंपाइल की गई हैं. (यह तब काम आ सकता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.)

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

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

resources

List of labels; optional

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

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

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

classpath_resources

List of labels; optional

इस विकल्प का इस्तेमाल तब तक न करें, जब तक यह किसी और तरीके से न हो)

रिसॉर्स की ऐसी सूची जो जावा ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद, सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी की मदद करना है जिनके लिए ज़रूरी है कि उनके संसाधन, क्लास पाथ पर "myconfig.xml" के तौर पर ढूंढे जाएं. नेमस्पेस की गड़बड़ी की वजह से, यह बदलाव सिर्फ़ बाइनरी फ़ाइलों पर लागू होता है.

create_executable

Boolean; optional; nonconfigurable; default is True

बाइनरी फ़ाइल एक्ज़ीक्यूटेबल है या नहीं. एक्ज़ीक्यूटेबल ऐसी बाइनरी जो ट्रांज़िटिव रनटाइम डिपेंडेंसी को डिप्लॉयमेंट जार में इकट्ठा करती हैं. हालांकि, इसे सीधे एक्ज़ीक्यूट नहीं किया जा सकता. अगर यह विशेषता सेट की जाती है, तो कोई रैपर स्क्रिप्ट नहीं बनाई जाती. अगर launcher या main_class एट्रिब्यूट सेट हैं, तो इसे 0 पर सेट करना एक गड़बड़ी होती है.
deploy_manifest_lines

List of strings; optional

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

List of strings; optional

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

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

jvm_flags

List of strings; optional

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

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

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

launcher

Label; optional

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

डिफ़ॉल्ट रूप से, Bazel सामान्य 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; optional

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

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

plugins

List of labels; optional

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

List of labels; optional

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

String; optional

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

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

runtime_deps

List of labels; optional

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

Integer; optional; default is 0

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

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

test_class

String; optional

टेस्ट रनर से लोड किया गया Java क्लास.

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

यह एट्रिब्यूट उस Java क्लास का नाम बताता है जिसे इस टेस्ट में चलाया जाना है. इसे सेट करना बहुत कम होता है. अगर यह आर्ग्युमेंट हटाया जाता है, तो इसका अनुमान टारगेट के name और उसके सोर्स-रिलेटिव पाथ का इस्तेमाल करके लगाया जाएगा. अगर टेस्ट जानी-पहचानी सोर्स की रूट के बाहर मौजूद है, तो Bazel एक गड़बड़ी रिपोर्ट करेगा. ऐसा तब होगा, जब 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

Boolean; optional; default is True

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

अगर यह एट्रिब्यूट गलत पर सेट है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े --java_launcher फ़्लैग को इस टारगेट के लिए अनदेखा कर दिया जाएगा.

use_testrunner

Boolean; optional; default is True

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

java_package_config

नियम का सोर्स देखें
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

Name; required

इस टारगेट के लिए खास नाम.

data

List of labels; optional

रनटाइम के दौरान, इस कॉन्फ़िगरेशन के लिए ज़रूरी फ़ाइलों की सूची.
javacopts

List of strings; optional

Java कंपाइलर फ़्लैग.
packages

List of labels; optional

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

java_plugins

नियम का सोर्स देखें
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 कंपाइलर के लिए प्लग इन बताता है. इस समय, व्याख्या करने की सुविधा सिर्फ़ एक तरह के प्लग इन के साथ काम करती है. प्लग इन के हिसाब से, plugins एट्रिब्यूट इस्तेमाल करके, java_library या java_binary का नियम लागू हो सकता है. java_library, प्लग इन को उन लाइब्रेरी में भी अपने-आप एक्सपोर्ट कर सकता है जो exported_plugins का इस्तेमाल करके, सीधे उस पर निर्भर करती हैं.

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

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

processor_class तर्क को जोड़ने के अलावा, तर्क java_library के जैसे होते हैं.

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए खास नाम.

deps

List of labels; optional

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

deps में दिए गए java_library नियमों से बनाए गए जार, इस नियम के कंपाइल होने में लगने वाले क्लास पाथ पर होंगे. इसके अलावा, अपने deps, runtime_deps, और exports को ट्रांज़िट समय में बंद कर दिया जाएगा और रनटाइम क्लास पाथ का इस्तेमाल किया जाएगा.

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

srcs

List of labels; optional

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

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

.srcjar टाइप की सोर्स फ़ाइलें अनपैक की गई हैं और कंपाइल की गई हैं. (यह तब काम आ सकता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.)

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

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

data

List of labels; optional

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

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

resources

List of labels; optional

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

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

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

generates_api

Boolean; optional; default is False

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

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

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

javacopts

List of strings; optional

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

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

Boolean; optional; default is False

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

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

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

output_licenses

Licence type; optional

common attributes देखें
plugins

List of labels; optional

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

String; optional

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

List of labels; optional

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

List of labels; optional

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

String; optional

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_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

Name; required

इस टारगेट के लिए खास नाम.

srcs

List of labels; optional

रनटाइम में मौजूद सभी फ़ाइलें.
default_cds

Label; optional

हर्मेटिक java_runtime के लिए डिफ़ॉल्ट सीडीएस संग्रह. जब java_binary टारगेट के लिए हर्मेटिक को चालू किया जाता है और अगर टारगेट, classlist एट्रिब्यूट को तय करके अपना खुद का सीडीएस संग्रह नहीं देता है, तो java_runtime डिफ़ॉल्ट सीडीएस को इंटरनल डिप्लॉयमेंट जेएआर में पैकेज किया जाता है.
hermetic_srcs

List of labels; optional

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

Label; optional

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

String; optional

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

Label; optional

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

Integer; optional; default is 0

Java रनटाइम का फ़ीचर वर्शन. उदाहरण के लिए, पूर्णांक Runtime.version().feature() दिया गया.

java_toolchain

नियम का सोर्स देखें
java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_with, deprecation, deps_checker, distribs, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_workers, javacopts, jvm_opts, licenses, oneversion, oneversion_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

Name; required

इस टारगेट के लिए खास नाम.

android_lint_data

List of labels; optional

android_lint_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध टूल के लेबल.
android_lint_jvm_opts

List of strings; optional

Android लिंट का इस्तेमाल करते समय, जेवीएम के लिए आर्ग्युमेंट की सूची.
android_lint_opts

List of strings; optional

Android लिंट आर्ग्युमेंट की सूची.
android_lint_package_configuration

List of labels; optional

Android लिंट कॉन्फ़िगरेशन, जिसे तय किए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
android_lint_runner

Label; optional

Android लिंट रनर का लेबल, अगर कोई हो.
bootclasspath

List of labels; optional

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

List of labels; optional

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

Boolean; optional; default is False

यह उन डिवाइस पर हेडर कंपाइलेशन को बंद करने के लिए --java_header_compilation को ओवरराइड करता है, जो इस पर काम नहीं करते. उदाहरण के लिए, JDK 7 Bazel.
genclass

List of labels; required

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

List of labels; optional

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

List of labels; optional

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

इस टूल पर एनोटेशन प्रोसेसिंग की सुविधा नहीं है.

ijar

List of labels; required

लागू करने के लिए इज़र लेबल का लेबल.
jacocorunner

Label; optional

जैकोकोकवरेज रनर का लेबल, जार डिप्लॉय करता है.
java_runtime

Label; required

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

List of labels; required

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

List of labels; optional

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

List of strings; optional

JavaBuilder का इस्तेमाल करने के दौरान, जेवीएम के लिए आर्ग्युमेंट की सूची.
javac_supports_multiplex_workers

Boolean; optional; default is True

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

Boolean; optional; default is True

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

List of strings; optional

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

List of strings; optional

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

Label; optional

एक-वर्शन वाली बाइनरी का लेबल.
oneversion_whitelist

Label; optional

एक संस्करण वाली व्हाइटलिस्ट का लेबल.
package_configuration

List of labels; optional

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

Label; optional; default is @bazel_tools//tools/jdk:proguard_whitelister

ProGuard अनुमति देने वाली कंपनी का लेबल.
resourcejar

List of labels; optional

रिसॉर्स जार बिल्डर एक्ज़ीक्यूटेबल का लेबल.
singlejar

List of labels; required

सिंगलजर डिप्लॉयमेंट जार का लेबल.
source_version

String; optional

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

String; optional

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

Label; optional

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

List of labels; optional

jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध टूल के लेबल.
turbine_data

List of labels; optional

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

List of strings; optional

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

List of strings; optional

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