नियम
- java_binary
- java_Import
- java_library
- java_lite_proto_library
- java_proto_library
- java_test
- java_package_config
- java_plugins
- java_runtime
- java_toolchain
java_binary
नियम का सोर्स देखेंjava_binary(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, output_licenses, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
यह Java संग्रह (जैर फ़ाइल) बनाता है. साथ ही, इस नाम के समान नाम वाली एक रैपर शेल स्क्रिप्ट भी बनाता है. रैपर शेल स्क्रिप्ट एक क्लासपाथ का इस्तेमाल करती है, जिसमें अन्य चीज़ों के अलावा, हर उस लाइब्रेरी के लिए एक जार फ़ाइल शामिल होती है, जिस पर बाइनरी निर्भर करती है.
रैपर स्क्रिप्ट कई खास झंडों को स्वीकार करती है. रैपर के स्वीकार किए जाने वाले कॉन्फ़िगर किए जा सकने वाले फ़्लैग और एनवायरमेंट वैरिएबल की सूची के लिए,
//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 |
इस टारगेट के लिए खास नाम. उस सोर्स फ़ाइल के नाम का इस्तेमाल करना अच्छा रहता है जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है (एक्सटेंशन को छोटा करके). उदाहरण के लिए, अगर आपके एंट्री पॉइंट को Main.java कहा जाता है, तो आपका नाम Main हो सकता है.
|
deps
|
deps में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें.
|
srcs
|
नियम: अगर नियम (आम तौर पर
यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर किसी |
resources
|
अगर रिसॉर्स बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. |
classpath_resources
|
रिसॉर्स की ऐसी सूची जो जावा ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद, सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी की मदद करना है जिनके लिए ज़रूरी है कि उनके संसाधन, क्लास पाथ पर |
create_executable
|
launcher या main_class एट्रिब्यूट
सेट हैं, तो इसे 0 पर सेट करना एक गड़बड़ी होती है.
|
deploy_env
|
java_binary टारगेट की सूची.
इस प्लग इन को सेट करते समय, ऐसा प्लग इन बनाएं जो किसी दूसरे java_binary को लोड करेगा.इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ और डिप्लॉयमेंट जार से सभी डिपेंडेंसी शामिल नहीं होती हैं. ये बाइनरी, बाइनरी और deploy_env में दिए गए टारगेट के बीच शेयर की जाती हैं.
|
deploy_manifest_lines
|
*_deploy.jar टारगेट के लिए जनरेट की गई
META-INF/manifest.mf फ़ाइल में जोड़ी जाने वाली लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में "वैरिएबल बनाएं" विकल्प
नहीं होगा.
|
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद जावा में पास किए जाते हैं. |
jvm_flags
|
Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल होती है (यह सभी डिपेंडेंट जार को ढूंढता है) और सही Java अनुवादक बनाता है.
रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में मुख्य क्लास का नाम और उसके बाद ध्यान दें कि इस एट्रिब्यूट से |
launcher
|
bin/java प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा.
टारगेट, cc_binary होना चाहिए. cc_binary , जो
Java इनोवेशन एपीआई को लागू करता है उसे इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है.
डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते ध्यान दें कि आपके नेटिव विज्ञापन (C++, SWIG, JNI) डिपेंडेंसी अलग तरीके से बनाई जाएंगी. यह इस बात पर निर्भर करता है कि आपने JDK लॉन्चर या किसी अन्य लॉन्चर का इस्तेमाल किया है या नहीं:
डिफ़ॉल्ट JDK लॉन्चर के अलावा, किसी भी लॉन्चर का इस्तेमाल करने पर, |
main_class
|
main() तरीके से क्लास का नाम.
अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो इसे srcs=[...] सूची की ज़रूरत नहीं होती.
इसलिए, इस एट्रिब्यूट का इस्तेमाल करके, ऐसी Java लाइब्रेरी से एक्ज़ीक्यूटेबल बनाया जा सकता है जिसमें पहले से ही एक या एक से ज़्यादा main() तरीके हैं.
इस एट्रिब्यूट की वैल्यू कोई क्लास नाम है, सोर्स फ़ाइल नहीं. क्लास
रनटाइम पर उपलब्ध होनी चाहिए; इसे इस नियम ( |
plugins
|
java_plugin को इस नियम के बनाए जाने पर चलाया जाएगा. लाइब्रेरी में, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लग इन लिया जा सकता है. प्लग इन से
जनरेट हुए रिसॉर्स को इस नियम के नतीजे वाले जार में शामिल किया जाएगा.
|
resource_jars
|
|
resource_strip_prefix
|
अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को |
runtime_deps
|
deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन
कंपाइल-टाइम क्लास पाथ पर नहीं. सिर्फ़ रनटाइम के लिए ज़रूरी डिपेंडेंसी
यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को runtime_deps और deps , दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.
|
stamp
|
स्टैंपर की गई बाइनरी को तब तक फिर से नहीं बनाया जाता है, जब तक उनकी डिपेंडेंसी नहीं बदलती. |
use_launcher
|
अगर यह एट्रिब्यूट गलत पर सेट है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े |
use_testrunner
|
com.google.testing.junit.runner.BazelTestRunner ) क्लास का इस्तेमाल करें. साथ ही, टेस्ट रनर को bazel.test_suite सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास उपलब्ध कराएं.
आप इससे डिफ़ॉल्ट व्यवहार को बदल सकते हैं. इसका इस्तेमाल java_test नियमों के लिए टेस्ट रनर का इस्तेमाल करने और java_binary नियमों के लिए नहीं किया जा सकता. ऐसा लगता है कि
आप ऐसा नहीं करना चाहेंगे. AllTest नियमों का इस्तेमाल एक ही ऐसे नियम के लिए होता है जिन्हें किसी अन्य नियम से शुरू किया जाता है (उदाहरण के लिए, जांच करने से पहले डेटाबेस को सेट अप करने के लिए). AllTest
नियम को java_binary के तौर पर बताया जाना चाहिए. हालांकि,
इसके लिए, टेस्ट रनर का इस्तेमाल मुख्य एंट्री पॉइंट के तौर पर किया जाना चाहिए.
टेस्ट रनर क्लास का नाम, main_class एट्रिब्यूट से बदला जा सकता है.
|
java_Import
नियम का सोर्स देखेंjava_import(name, deps, data, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, visibility)
यह नियम java_library
और java_binary
नियमों के लिए, पहले से कंपाइल की गई .jar
फ़ाइलों को लाइब्रेरी के तौर पर इस्तेमाल करने की अनुमति देता है.
उदाहरण
java_import( name = "maven_model", jars = [ "maven_model/maven-aether-provider-3.2.3.jar", "maven_model/maven-model-3.2.3.jar", "maven_model/maven-model-builder-3.2.3.jar", ], )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए खास नाम. |
deps
|
|
constraints
|
|
exports
|
|
jars
|
|
neverlink
|
tools.jar .
|
proguard_specs
|
android_binary टारगेट में जोड़ा जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ आसान नियम, जैसे कि -dontnote, -dontwarn, मान लेने वाले नुकसान, और -keep से शुरू होने वाले नियम होने चाहिए. दूसरे विकल्प, सिर्फ़ android_binary के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि वे ऑटोमैटिक मर्ज की प्रोसेस में शामिल न हों.
|
runtime_deps
|
|
srcjar
|
|
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 |
इस टारगेट के लिए खास नाम. |
deps
|
deps में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें.
इसके उलट, |
srcs
|
नियम: अगर नियम (आम तौर पर
यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर किसी |
data
|
data में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें.
|
resources
|
अगर रिसॉर्स बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. |
exported_plugins
|
java_plugin की ऐसी सूची (जैसे कि एनोटेशन प्रोसेसर) की सूची.
|
exports
|
यहां जोड़े गए नियमों की मदद से माता-पिता के नियम यहां बताए गए हैं, जैसे कि माता-पिता ने खास तौर पर इन नियमों का पालन किया है. यह सामान्य (बिना एक्सपोर्ट किया गया)
खास जानकारी: अगर किसी नियम के
मान लें कि A, B और B, C पर निर्भर करते हैं. इस मामले में
C, A की ट्रांज़िटिव डिपेंडेंसी है. इसलिए, C के सोर्स और फिर से बनाए जाने की वजह से
सब कुछ सही तरीके से दोबारा बन जाएगा. हालांकि, वह C में कक्षाओं का इस्तेमाल नहीं कर पाएगा. ऐसा करने के लिए,
A को अपनी एक्सपोर्ट की गई लाइब्रेरी को बंद करने पर, वे सभी पैरंट नियम उपलब्ध हो जाते हैं जो इस्तेमाल किए जा सकते हैं. थोड़ा अलग उदाहरण देखें: A, B पर निर्भर करता है, C और D पर निर्भर है, और C को भी एक्सपोर्ट करता है, लेकिन D नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अगर C और D ने कुछ लाइब्रेरी, C, और D को एक्सपोर्ट किया है, तो A सिर्फ़ C को ऐक्सेस कर सकता है, लेकिन D को नहीं.
अहम जानकारी: एक्सपोर्ट किया गया नियम नियमित डिपेंडेंसी नहीं होता है. पिछले उदाहरण को ध्यान में रखते हुए,
अगर B C को एक्सपोर्ट करता है और C को भी इस्तेमाल करना चाहता है, तो उसे उसे अपनी
|
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद जावा में पास किए जाते हैं. |
neverlink
|
tools.jar होते हैं.
ध्यान दें कि अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि वह सिर्फ़ उन जगहों पर अलग हो जहां जेएलएस कंपाइलर को इनलाइन में आने से रोकती है (या जेएलएस के आने वाले सभी वर्शन के लिए होल्ड होनी चाहिए). |
plugins
|
java_plugin को इस नियम के बनाए जाने पर चलाया जाएगा. लाइब्रेरी में, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लग इन लिया जा सकता है. प्लग इन से
जनरेट हुए रिसॉर्स को इस नियम के नतीजे वाले जार में शामिल किया जाएगा.
|
proguard_specs
|
android_binary टारगेट में जोड़ा जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ आसान नियम, जैसे कि -dontnote, -dontwarn, मान लेने वाले नुकसान, और -keep से शुरू होने वाले नियम होने चाहिए. दूसरे विकल्प, सिर्फ़ android_binary के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि वे ऑटोमैटिक मर्ज की प्रोसेस में शामिल न हों.
|
resource_jars
|
|
resource_strip_prefix
|
अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को |
runtime_deps
|
deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन
कंपाइल-टाइम क्लास पाथ पर नहीं. सिर्फ़ रनटाइम के लिए ज़रूरी डिपेंडेंसी
यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को runtime_deps और deps , दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.
|
java_lite_proto_library
नियम का सोर्स देखेंjava_lite_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
java_lite_proto_library
, .proto
फ़ाइलों से Java कोड जनरेट करता है.
deps
को proto_library
नियमों पर ले जाना ज़रूरी है.
उदाहरण:
java_library( name = "lib", deps = [":foo"], ) java_lite_proto_library( name = "foo", deps = [":bar"], ) proto_library( name = "bar", )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए खास नाम. |
deps
|
proto_library नियमों की सूची, जिसके लिए Java कोड जनरेट करना है.
|
java_proto_library
नियम का सोर्स देखेंjava_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
java_proto_library
, .proto
फ़ाइलों से Java कोड जनरेट करता है.
deps
को proto_library
नियमों पर ले जाना ज़रूरी है.
उदाहरण:
java_library( name = "lib", deps = [":foo_java_proto"], ) java_proto_library( name = "foo_java_proto", deps = [":foo_proto"], ) proto_library( name = "foo_proto", )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए खास नाम. |
deps
|
proto_library नियमों की सूची, जिसके लिए Java कोड जनरेट करना है.
|
java_test
नियम का सोर्स देखेंjava_test(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
java_test()
नियम, Java की जांच को कंपाइल करता है. टेस्ट आपके टेस्ट कोड के चारों ओर मौजूद बाइनरी रैपर है. टेस्ट रनर की मुख्य विधि को मुख्य क्लास को कंपाइल करने के बजाय शुरू किया जाता है.
इंप्लिसिट आउटपुट टारगेट
name.jar
एक Java संग्रह है.name_deploy.jar
डिप्लॉयमेंट के लिए सही Java संग्रह. (अगर अनुरोध साफ़ तौर पर किया गया हो, सिर्फ़ तब बनाया जाता है.) ज़्यादा जानकारी के लिए, java_binary सेname_deploy.jar
आउटपुट का ब्यौरा देखें.
java_binary() आर्ग्युमेंट पर सेक्शन देखें. इस नियम में टेस्ट के सभी नियम (*_test)का इस्तेमाल करने वाले सभी एट्रिब्यूट का भी इस्तेमाल किया जा सकता है.
उदाहरण
java_library( name = "tests", srcs = glob(["*.java"]), deps = [ "//java/com/foo/base:testResources", "//java/com/foo/testing/util", ], ) java_test( name = "AllTests", size = "small", runtime_deps = [ ":tests", "//util/mysql", ], )
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए खास नाम. |
deps
|
deps में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें.
|
srcs
|
नियम: अगर नियम (आम तौर पर
यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर किसी |
resources
|
अगर रिसॉर्स बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. |
classpath_resources
|
रिसॉर्स की ऐसी सूची जो जावा ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद, सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी की मदद करना है जिनके लिए ज़रूरी है कि उनके संसाधन, क्लास पाथ पर |
create_executable
|
launcher या main_class एट्रिब्यूट
सेट हैं, तो इसे 0 पर सेट करना एक गड़बड़ी होती है.
|
deploy_manifest_lines
|
*_deploy.jar टारगेट के लिए जनरेट की गई
META-INF/manifest.mf फ़ाइल में जोड़ी जाने वाली लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में "वैरिएबल बनाएं" विकल्प
नहीं होगा.
|
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद जावा में पास किए जाते हैं. |
jvm_flags
|
Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल होती है (यह सभी डिपेंडेंट जार को ढूंढता है) और सही Java अनुवादक बनाता है.
रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में मुख्य क्लास का नाम और उसके बाद ध्यान दें कि इस एट्रिब्यूट से |
launcher
|
bin/java प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा.
टारगेट, cc_binary होना चाहिए. cc_binary , जो
Java इनोवेशन एपीआई को लागू करता है उसे इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है.
डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते ध्यान दें कि आपके नेटिव विज्ञापन (C++, SWIG, JNI) डिपेंडेंसी अलग तरीके से बनाई जाएंगी. यह इस बात पर निर्भर करता है कि आपने JDK लॉन्चर या किसी अन्य लॉन्चर का इस्तेमाल किया है या नहीं:
डिफ़ॉल्ट JDK लॉन्चर के अलावा, किसी भी लॉन्चर का इस्तेमाल करने पर, |
main_class
|
main() तरीके से क्लास का नाम.
अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो इसे srcs=[...] सूची की ज़रूरत नहीं होती.
इसलिए, इस एट्रिब्यूट का इस्तेमाल करके, ऐसी Java लाइब्रेरी से एक्ज़ीक्यूटेबल बनाया जा सकता है जिसमें पहले से ही एक या एक से ज़्यादा main() तरीके हैं.
इस एट्रिब्यूट की वैल्यू कोई क्लास नाम है, सोर्स फ़ाइल नहीं. क्लास
रनटाइम पर उपलब्ध होनी चाहिए; इसे इस नियम ( |
plugins
|
java_plugin को इस नियम के बनाए जाने पर चलाया जाएगा. लाइब्रेरी में, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लग इन लिया जा सकता है. प्लग इन से
जनरेट हुए रिसॉर्स को इस नियम के नतीजे वाले जार में शामिल किया जाएगा.
|
resource_jars
|
|
resource_strip_prefix
|
अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को |
runtime_deps
|
deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन
कंपाइल-टाइम क्लास पाथ पर नहीं. सिर्फ़ रनटाइम के लिए ज़रूरी डिपेंडेंसी
यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को runtime_deps और deps , दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.
|
stamp
|
स्टैंपर की गई बाइनरी को तब तक फिर से नहीं बनाया जाता है, जब तक उनकी डिपेंडेंसी नहीं बदलती. |
test_class
|
डिफ़ॉल्ट रूप से, अगर इस आर्ग्युमेंट को तय नहीं किया गया है, तो लेगसी मोड का इस्तेमाल किया जाता है. पहले तर्क पर,
यह एट्रिब्यूट उस Java क्लास का नाम बताता है जिसे इस टेस्ट में चलाया जाना है. इसे सेट करना बहुत कम होता है. अगर यह आर्ग्युमेंट हटाया जाता है, तो इसका अनुमान टारगेट के
JUnit3 के लिए, टेस्ट क्लास में या तो
इस एट्रिब्यूट की मदद से, कई |
use_launcher
|
अगर यह एट्रिब्यूट गलत पर सेट है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े |
use_testrunner
|
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 |
इस टारगेट के लिए खास नाम. |
data
|
|
javacopts
|
|
packages
|
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 |
इस टारगेट के लिए खास नाम. |
deps
|
deps में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें.
इसके उलट, |
srcs
|
नियम: अगर नियम (आम तौर पर
यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर किसी |
data
|
data में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें.
|
resources
|
अगर रिसॉर्स बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. |
generates_api
|
अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो अन्य नियम, इस बात पर निर्भर करते हैं कि जनरेट किए गए कोड का रेफ़रंस सिर्फ़ तब दिया जा सकता है, जब कंपाइल करने की कार्रवाइयां, जनरेट होने वाले नियम के बाद शेड्यूल की गई हों. इस विशेषता का इस्तेमाल करके, Bazel को यह निर्देश दिया जाता है कि वह java_header_compilation के चालू होने पर, शेड्यूल करने से जुड़े प्रतिबंध लागू करे. चेतावनी: बिल्ड परफ़ॉर्मेंस पर इस एट्रिब्यूट का असर पड़ता है. ज़रूरत पड़ने पर ही इसका इस्तेमाल करें. |
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद जावा में पास किए जाते हैं. |
neverlink
|
tools.jar होते हैं.
ध्यान दें कि अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि वह सिर्फ़ उन जगहों पर अलग हो जहां जेएलएस कंपाइलर को इनलाइन में आने से रोकती है (या जेएलएस के आने वाले सभी वर्शन के लिए होल्ड होनी चाहिए). |
output_licenses
|
common attributes
देखें
|
plugins
|
java_plugin को इस नियम के बनाए जाने पर चलाया जाएगा. लाइब्रेरी में, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लग इन लिया जा सकता है. प्लग इन से
जनरेट हुए रिसॉर्स को इस नियम के नतीजे वाले जार में शामिल किया जाएगा.
|
processor_class
|
|
proguard_specs
|
android_binary टारगेट में जोड़ा जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ आसान नियम, जैसे कि -dontnote, -dontwarn, मान लेने वाले नुकसान, और -keep से शुरू होने वाले नियम होने चाहिए. दूसरे विकल्प, सिर्फ़ android_binary के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि वे ऑटोमैटिक मर्ज की प्रोसेस में शामिल न हों.
|
resource_jars
|
|
resource_strip_prefix
|
अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को |
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 |
इस टारगेट के लिए खास नाम. |
srcs
|
|
default_cds
|
java_runtime के लिए डिफ़ॉल्ट सीडीएस संग्रह. जब java_binary टारगेट के लिए हर्मेटिक
को चालू किया जाता है और अगर टारगेट,
classlist एट्रिब्यूट को तय करके
अपना खुद का सीडीएस संग्रह नहीं देता है, तो
java_runtime डिफ़ॉल्ट सीडीएस को इंटरनल डिप्लॉयमेंट जेएआर में पैकेज किया जाता है.
|
hermetic_srcs
|
|
java
|
|
java_home
|
srcs और java एट्रिब्यूट की वैल्यू खाली होनी चाहिए.
|
lib_modules
|
|
version
|
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 |
इस टारगेट के लिए खास नाम. |
android_lint_data
|
|
android_lint_jvm_opts
|
|
android_lint_opts
|
|
android_lint_package_configuration
|
|
android_lint_runner
|
|
bootclasspath
|
|
deps_checker
|
|
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
|
|
oneversion
|
|
oneversion_whitelist
|
|
package_configuration
|
|
proguard_allowlister
|
|
resourcejar
|
|
singlejar
|
|
source_version
|
|
target_version
|
|
timezone_data
|
|
tools
|
|
turbine_data
|
|
turbine_jvm_opts
|
|
xlint
|
|