नियम
- java_binary
- java_import
- java_library
- java_lite_proto_library
- java_proto_library
- java_test
- java_package_configuration
- java_plugin
- java_runtime
- java_toolchain
java_binary
नियम का सोर्स देखेंjava_binary(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, output_licenses, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
यह Java संग्रह ("जार फ़ाइल") बनाता है. साथ ही, नियम के नाम से ही एक रैपर शेल स्क्रिप्ट बनाता है.
रैपर शेल स्क्रिप्ट एक ऐसे क्लासपाथ का इस्तेमाल करती है जिसमें दूसरी चीज़ों के अलावा, हर उस लाइब्रेरी के लिए एक जार फ़ाइल
शामिल होती है जिस पर बाइनरी निर्भर करती है. रैपर शेल स्क्रिप्ट चलाते समय, किसी भी खाली
JAVABIN
एनवायरमेंट वैरिएबल को Bazel के --java_runtime_version
फ़्लैग के ज़रिए बताए गए वर्शन के मुकाबले प्राथमिकता दी जाएगी.
रैपर स्क्रिप्ट कई यूनीक फ़्लैग स्वीकार करती है. कॉन्फ़िगर करने लायक फ़्लैग और एनवायरमेंट वैरिएबल की सूची देखने के लिए,
//src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt
देखें. यह वैरिएबल रैपर स्वीकार करता है.
इंप्लिसिट आउटपुट टारगेट
name.jar
: Java संग्रह, जिसमें क्लास की फ़ाइलें और बाइनरी की डिपेंडेंसी से संबंधित अन्य संसाधन मौजूद होते हैं.name-src.jar
: सोर्स वाला संग्रह ("सोर्स जार").name_deploy.jar
: Java संग्रह, जो डिप्लॉयमेंट के लिए सही है (सिर्फ़ साफ़ तौर पर अनुरोध किए जाने पर बनाया गया).अपने नियम के लिए
<name>_deploy.jar
टारगेट बनाने पर, मेनिफ़ेस्ट के साथ पूरी जानकारी वाली एक जार फ़ाइल बनती है. इससे, इसेjava -jar
कमांड या रैपर स्क्रिप्ट के--singlejar
विकल्प की मदद से चलाया जा सकता है.java -jar
को रैपर स्क्रिप्ट का इस्तेमाल करने का सुझाव दिया जाता है, क्योंकि यह JVM फ़्लैग और नेटिव लाइब्रेरी लोड करने के विकल्प भी पास करता है.डिप्लॉय किए गए जार में वे सभी क्लास शामिल होती हैं जो उस क्लासलोडर को मिलेंगी जिसने बाइनरी की रैपर स्क्रिप्ट से शुरू से आखिर तक क्लासपाथ को खोजा था. इसमें डिपेंडेंसी के लिए ज़रूरी नेटिव लाइब्रेरी भी शामिल हैं. ये रनटाइम के दौरान, जेवीएम में अपने-आप लोड हो जाती हैं.
अगर आपका टारगेट किसी लॉन्चर एट्रिब्यूट के बारे में बताता है, तो सामान्य JAR फ़ाइल होने के बजाय, _deploy.jar एक नेटिव बाइनरी होगा. इसमें लॉन्चर शामिल होगा. साथ ही, इसमें आपके नियम की नेटिव (C++) डिपेंडेंसी भी शामिल होंगी, जो हमें स्टैटिक बाइनरी से जुड़ी होती हैं. जार फ़ाइल के बाइट को नेटिव बाइनरी में जोड़ दिया जाएगा. इससे एक बाइनरी ब्लॉब बन जाएगा, जिसमें एक्ज़ीक्यूटेबल और Java कोड, दोनों की जानकारी शामिल होगी. जार फ़ाइल को उसी तरह एक्ज़ीक्यूट किया जा सकता है जिस तरह किसी नेटिव बाइनरी को एक्ज़ीक्यूट किया गया था.
name_deploy-src.jar
: एक संग्रह जिसमें टारगेट के सीमित किए जाने के समय से इकट्ठा किए गए सोर्स मौजूद होते हैं. ये उनdeploy.jar
की क्लास से मेल खाएंगे जिनमें जार का कोई मिलता-जुलता सोर्स नहीं है.
java_binary
नियम में srcs
के बिना, deps
एट्रिब्यूट इस्तेमाल करने की अनुमति नहीं है. इस तरह के नियम के लिए, runtime_deps
से मिला main_class
ज़रूरी होता है.
नीचे दिया गया कोड स्निपेट एक सामान्य गलती दिखाता है:
java_binary( name = "DontDoThis", srcs = [ ..., "GeneratedJavaFile.java", # a generated .java file ], deps = [":generating_rule"], # rule that generates that file )
इसके बजाय यह करें:
java_binary( name = "DoThisInstead", srcs = [ ..., ":generating_rule", ], )
तर्क
विशेषताएं | |
---|---|
name |
नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम. सोर्स फ़ाइल के नाम का इस्तेमाल करें. यह वही नाम होना चाहिए जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट हो. (एक्सटेंशन को शामिल नहीं करते हुए). उदाहरण के लिए, अगर आपका एंट्री पॉइंट Main.java है, तो आपका नाम Main हो सकता है.
|
deps
|
लेबल की सूची; deps के बारे में की गई सामान्य टिप्पणियां देखें.
|
srcs
|
लेबल की सूची;
नियम: अगर नियम (आम तौर पर
आम तौर पर, यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर कोई |
resources
|
लेबल की सूची;
अगर संसाधनों के बारे में बताया गया है, तो उन्हें जार में, कंपाइलेशन से बनाई गई सामान्य
संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं. |
classpath_resources
|
लेबल की सूची;
उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का मकसद
सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना होता है जिनके लिए ज़रूरी है कि उनके संसाधन
क्लासपाथ पर ठीक |
create_executable
|
बूलियन; कॉन्फ़िगर करने योग्य; डिफ़ॉल्ट java_single_jar का इस्तेमाल करें.
|
deploy_env
|
लेबल की सूची; java_binary टारगेट की सूची, जो इस बाइनरी के डिप्लॉयमेंट एनवायरमेंट को दिखाती है.
कोई ऐसा प्लगिन बनाते समय इस एट्रिब्यूट को सेट करें जिसे किसी दूसरे
java_binary से लोड किया जाएगा.इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉय किए गए जार) की वे सभी डिपेंडेंसी शामिल नहीं होंगी जिन्हें इस बाइनरी और deploy_env में बताए गए टारगेट के बीच शेयर किया जाता है.
|
deploy_manifest_lines
|
स्ट्रिंग की सूची; *_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट पर, "वैरिएबल बनाएं" से बदली गई वैल्यू का इस्तेमाल नहीं किया जाता है.
|
javacopts
|
स्ट्रिंग की सूची; कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद, javac को पास किए जाते हैं. |
jvm_flags
|
स्ट्रिंग की सूची; Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है.
रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, ध्यान दें कि इस एट्रिब्यूट का |
launcher
|
लेबल; bin/java प्रोग्राम के बजाय,
आपके Java प्रोग्राम को चलाने के लिए किया जाएगा.
टारगेट cc_binary होना चाहिए.
Java इनवोकेशन एपीआई लागू करने वाले किसी भी cc_binary को, इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है.
डिफ़ॉल्ट रूप से, 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, 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)
इस नियम के तहत, 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
|
लेबल की सूची; |
data
|
लेबल की सूची; |
add_exports
|
स्ट्रिंग की सूची; module या package को ऐक्सेस करने की अनुमति दें.
यह javac और JVM --add-exports= फ़्लैग के मुताबिक होता है. |
add_opens
|
स्ट्रिंग की सूची; module या
package को बेहतर तरीके से ऐक्सेस करने की अनुमति दें.
यह javac और JVM --add-opens= फ़्लैग के मुताबिक है. |
constraints
|
स्ट्रिंग की सूची; |
exports
|
लेबल की सूची; |
jars
|
लेबल की सूची; आवश्यक Java टारगेट को दी गई JAR फ़ाइलों की सूची, जो इस टारगेट पर निर्भर करती है. |
neverlink
|
बूलियन; डिफ़ॉल्ट tools.jar हैं.
|
proguard_specs
|
लेबल की सूची; android_binary टारगेट में जोड़ दिया जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ एक आदर्श नियम होना चाहिए, जैसे कि -dontnote, -dontvarn,
assumenosideimpact और -keep से शुरू होने वाले नियम. दूसरे विकल्प सिर्फ़
android_binary के proGuard_specs में ही दिख सकते हैं, ताकि नॉन-टॉलॉजिकल इंटिग्रेशन को पक्का किया जा सके.
|
runtime_deps
|
लेबल की सूची; |
srcjar
|
लेबल; |
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 के बारे में सामान्य टिप्पणियां देखें.
वहीं दूसरी ओर, |
srcs
|
लेबल की सूची;
नियम: अगर नियम (आम तौर पर
दूसरी सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद न हो. ऐसा न होने पर, गड़बड़ी का मैसेज मिलता है.
यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर आपने |
data
|
लेबल की सूची; data के बारे में सामान्य टिप्पणियां देखें.
|
resources
|
लेबल की सूची; संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें जार में, कंपाइलेशन से बनाई गई सामान्य |
add_exports
|
स्ट्रिंग की सूची; module या package को ऐक्सेस करने की अनुमति दें.
यह javac और JVM --add-exports= फ़्लैग के मुताबिक होता है. |
add_opens
|
स्ट्रिंग की सूची; module या
package को बेहतर तरीके से ऐक्सेस करने की अनुमति दें.
यह javac और JVM --add-opens= फ़्लैग के मुताबिक है. |
bootclasspath
|
लेबल; |
exported_plugins
|
लेबल की सूची; java_plugin (जैसे, एनोटेशन प्रोसेसर) की सूची जो सीधे तौर पर इस लाइब्रेरी पर निर्भर हैं.
|
exports
|
लेबल की सूची;
यहां दिए गए लिस्टिंग के नियमों से, उन्हें पैरंट नियमों के लिए उपलब्ध कराया जाएगा, जैसे कि माता-पिता साफ़ तौर पर इन नियमों पर निर्भर करते हैं. यह सामान्य (एक्सपोर्ट नहीं किए जाने वाले)
खास जानकारी: X नियम Y में कोड को ऐक्सेस कर सकता है. ऐसा तब होता है, जब उनके बीच डिपेंडेंसी पाथ मौजूद होता है, जो
मान लें कि A, B पर निर्भर है और B, C पर निर्भर है. इस मामले में,
C, A की ट्रांज़िशनिव डिपेंडेंसी है. इसलिए, C के सोर्स बदलने और A को फिर से बनाने से, सब कुछ फिर से बनाने में मदद मिलेगी. हालांकि, A, C में क्लास इस्तेमाल नहीं कर पाएगा. इसकी अनुमति देने के लिए,
A को एक्सपोर्ट की गई लाइब्रेरी को बंद करने की सुविधा, सभी पैरंट नियमों के लिए उपलब्ध है. एक अलग उदाहरण लें: A, B पर निर्भर करता है, B पर C और D पर निर्भर करता है. साथ ही, C को एक्सपोर्ट करता है, D पर नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अब, अगर C और D ने कुछ लाइब्रेरी, C' और D' को एक्सपोर्ट किया है, तो A सिर्फ़ C' को ऐक्सेस कर सकता था, D' को नहीं.
ज़रूरी जानकारी: एक्सपोर्ट किया गया नियम, सामान्य डिपेंडेंसी नहीं है. पिछले उदाहरण की तरह ही, अगर B, C को एक्सपोर्ट करता है और उसे C का भी इस्तेमाल करना चाहता है, तो उसे भी इसे अपने |
javabuilder_jvm_flags
|
स्ट्रिंग की सूची; |
javacopts
|
स्ट्रिंग की सूची; कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद, javac को पास किए जाते हैं. |
neverlink
|
बूलियन; डिफ़ॉल्ट tools.jar हैं.
ध्यान दें कि अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग-अलग हो जहां जेएलएस, कंपाइलर को इनलाइन करने की अनुमति नहीं देता है. साथ ही, इसे जेएलएस के आने वाले सभी वर्शन के लिए भी होल्ड किया जाना चाहिए. |
plugins
|
लेबल की सूची; java_plugin को चलाया जाएगा. लाइब्रेरी, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से प्लग इन इनहेरिट कर सकती है. प्लग इन
से जनरेट किए गए संसाधन, इस नियम के जार में शामिल किए जाएंगे.
|
proguard_specs
|
लेबल की सूची; android_binary टारगेट में जोड़ दिया जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ एक आदर्श नियम होना चाहिए, जैसे कि -dontnote, -dontvarn,
assumenosideimpact और -keep से शुरू होने वाले नियम. दूसरे विकल्प सिर्फ़
android_binary के proGuard_specs में ही दिख सकते हैं, ताकि नॉन-टॉलॉजिकल इंटिग्रेशन को पक्का किया जा सके.
|
resource_strip_prefix
|
स्ट्रिंग;
अगर बताया गया है, तो इस पाथ प्रीफ़िक्स को |
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 संग्रह. (यह सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो.) ज़्यादा जानकारी के लिए, 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
|
लेबल की सूची;
नियम: अगर नियम (आम तौर पर
यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर |
data
|
लेबल की सूची; data के बारे में सामान्य टिप्पणियां देखें.
|
resources
|
लेबल की सूची; संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें जार में, कंपाइलेशन से बनाई गई सामान्य |
add_exports
|
स्ट्रिंग की सूची; module या package को ऐक्सेस करने की अनुमति दें.
यह javac और JVM --add-exports= फ़्लैग के मुताबिक होता है. |
add_opens
|
स्ट्रिंग की सूची; module या
package को बेहतर तरीके से ऐक्सेस करने की अनुमति दें.
यह javac और JVM --add-opens= फ़्लैग के मुताबिक है. |
bootclasspath
|
लेबल; |
classpath_resources
|
लेबल की सूची;
उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का मकसद, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना होता है जिनके संसाधनों को क्लासपाथ पर |
create_executable
|
बूलियन; डिफ़ॉल्ट java_single_jar का इस्तेमाल करें.
|
deploy_manifest_lines
|
स्ट्रिंग की सूची; *_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट की जगह "वैरिएबल" का इस्तेमाल नहीं किया जा सकता.
|
javacopts
|
स्ट्रिंग की सूची; कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद, javac को पास किए जाते हैं. |
jvm_flags
|
स्ट्रिंग की सूची; Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है.
रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में मुख्य क्लास का नाम होता है, जिसके बाद ध्यान दें कि इस एट्रिब्यूट का |
launcher
|
लेबल; bin/java प्रोग्राम के बजाय,
आपके Java प्रोग्राम को चलाने के लिए किया जाएगा.
टारगेट cc_binary होना चाहिए.
Java Invocat API को लागू करने वाले किसी भी cc_binary को, इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है.
डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते ध्यान दें कि आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी इस आधार पर अलग-अलग तरीके से बनाई जाएंगी कि आप JDK लॉन्चर का इस्तेमाल कर रहे हैं या किसी दूसरे लॉन्चर का:
डिफ़ॉल्ट JDK लॉन्चर के अलावा, किसी दूसरे लॉन्चर का इस्तेमाल करने पर,
|
main_class
|
स्ट्रिंग; main() तरीके से क्लास का नाम.
अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो उसे srcs=[...] सूची की ज़रूरत नहीं होती.
इसलिए, इस एट्रिब्यूट का इस्तेमाल करके Java लाइब्रेरी से एक्ज़ीक्यूटेबल बनाया जा सकता है, जिसमें पहले से ही एक या उससे ज़्यादा main() तरीके शामिल हैं.
इस एट्रिब्यूट की वैल्यू किसी क्लास का नाम है, न कि सोर्स फ़ाइल का. क्लास, रनटाइम के दौरान उपलब्ध होनी चाहिए: इसे इस नियम के ज़रिए ( |
neverlink
|
बूलियन; डिफ़ॉल्ट |
plugins
|
लेबल की सूची; java_plugin को चलाया जाएगा. लाइब्रेरी, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से प्लग इन इनहेरिट कर सकती है. प्लग इन
से जनरेट किए गए संसाधन, इस नियम के जार में शामिल किए जाएंगे.
|
resource_strip_prefix
|
स्ट्रिंग;
अगर बताया गया है, तो इस पाथ प्रीफ़िक्स को |
runtime_deps
|
लेबल की सूची; deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन इनके उलट, कंपाइल-टाइम क्लासपाथ पर नहीं. सिर्फ़ रनटाइम के लिए ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को runtime_deps और deps , दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.
|
stamp
|
पूर्णांक; डिफ़ॉल्ट
स्टैंप वाली बाइनरी फिर से नहीं बनाई जातीं, जब तक कि उनकी डिपेंडेंसी नहीं बदलती. |
test_class
|
स्ट्रिंग;
डिफ़ॉल्ट रूप से, अगर इस आर्ग्युमेंट का इस्तेमाल नहीं किया जाता है, तो लेगसी मोड का इस्तेमाल किया जाता है और
टेस्ट आर्ग्युमेंट का इस्तेमाल किया जाता है. पहले आर्ग्युमेंट पर,
यह एट्रिब्यूट, इस टेस्ट से चलाए जाने वाले Java क्लास का नाम बताता है. ऐसा बहुत कम होता है, जब इसे सेट करना पड़े. अगर यह तर्क शामिल नहीं किया जाता है,
तो टारगेट के
JUnit3 के लिए, टेस्ट क्लास को
यह एट्रिब्यूट कई |
use_launcher
|
बूलियन; डिफ़ॉल्ट अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए लॉन्चर एट्रिब्यूट और इससे जुड़े |
use_testrunner
|
बूलियन; डिफ़ॉल्ट 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
|
स्ट्रिंग की सूची; |
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
, Bazel से चलाए जाने वाले Java कंपाइलर के लिए प्लगिन के बारे में बताता है. फ़िलहाल, एनोटेशन प्रोसेसर ही काम करने वाले प्लग इन हैं. java_library
या
java_binary
नियम, plugins
एट्रिब्यूट के ज़रिए प्लगिन के आधार पर
प्लगिन चला सकता है. java_library
, प्लगिन को अपने-आप उन लाइब्रेरी में भी एक्सपोर्ट कर सकता है जो
exported_plugins
का इस्तेमाल करके, सीधे तौर पर इस पर निर्भर हैं.
इंप्लिसिट आउटपुट टारगेट
libname.jar
: Java संग्रह.
processor_class
तर्क को जोड़े जाने को छोड़कर, तर्क और java_library
एक जैसे होते हैं.
तर्क
विशेषताएं | |
---|---|
name |
नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम. |
deps
|
लेबल की सूची; deps के बारे में सामान्य टिप्पणियां देखें.
वहीं दूसरी ओर, |
srcs
|
लेबल की सूची;
नियम: अगर नियम (आम तौर पर
दूसरी सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद न हो. ऐसा न होने पर, गड़बड़ी का मैसेज मिलता है.
यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर आपने |
data
|
लेबल की सूची; data के बारे में सामान्य टिप्पणियां देखें.
|
resources
|
लेबल की सूची; संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें जार में, कंपाइलेशन से बनाई गई सामान्य |
add_exports
|
स्ट्रिंग की सूची; module या package को ऐक्सेस करने की अनुमति दें.
यह javac और JVM --add-exports= फ़्लैग के मुताबिक होता है. |
add_opens
|
स्ट्रिंग की सूची; module या
package को बेहतर तरीके से ऐक्सेस करने की अनुमति दें.
यह javac और JVM --add-opens= फ़्लैग के मुताबिक है. |
bootclasspath
|
लेबल; |
generates_api
|
बूलियन; डिफ़ॉल्ट अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो इस पर निर्भर अन्य नियम जनरेट किए गए कोड को सिर्फ़ तब बता सकते हैं, जब कंपाइल करने की कार्रवाइयां, जनरेट करने वाले नियम के बाद शेड्यूल की गई हों. यह एट्रिब्यूट, Bazel को -java_header_compilation के चालू होने पर, शेड्यूल करने से जुड़ी पाबंदियां लागू करने का निर्देश देता है. चेतावनी: इस एट्रिब्यूट का असर, ऐप्लिकेशन के बिल्ड की परफ़ॉर्मेंस पर पड़ता है. ज़रूरत पड़ने पर ही इसका इस्तेमाल करें. |
javabuilder_jvm_flags
|
स्ट्रिंग की सूची; |
javacopts
|
स्ट्रिंग की सूची; कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद, javac को पास किए जाते हैं. |
neverlink
|
बूलियन; डिफ़ॉल्ट tools.jar हैं.
ध्यान दें कि अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग-अलग हो जहां जेएलएस, कंपाइलर को इनलाइन करने की अनुमति नहीं देता है. साथ ही, इसे जेएलएस के आने वाले सभी वर्शन के लिए भी होल्ड किया जाना चाहिए. |
output_licenses
|
स्ट्रिंग की सूची; |
plugins
|
लेबल की सूची; java_plugin को चलाया जाएगा. लाइब्रेरी, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से प्लग इन इनहेरिट कर सकती है. प्लग इन
से जनरेट किए गए संसाधन, इस नियम के जार में शामिल किए जाएंगे.
|
processor_class
|
स्ट्रिंग; |
proguard_specs
|
लेबल की सूची; android_binary टारगेट में जोड़ दिया जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ एक आदर्श नियम होना चाहिए, जैसे कि -dontnote, -dontvarn,
assumenosideimpact और -keep से शुरू होने वाले नियम. दूसरे विकल्प सिर्फ़
android_binary के proGuard_specs में ही दिख सकते हैं, ताकि नॉन-टॉलॉजिकल इंटिग्रेशन को पक्का किया जा सके.
|
resource_strip_prefix
|
स्ट्रिंग;
अगर बताया गया है, तो इस पाथ प्रीफ़िक्स को |
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
|
लेबल; java_runtime के लिए डिफ़ॉल्ट CDS संग्रह. अगर java_binary टारगेट के लिए हेरमेटिक सुविधा चालू की जाती है और टारगेट classlist एट्रिब्यूट में जानकारी देकर अपना CDS संग्रह उपलब्ध नहीं कराता है, तो java_runtime डिफ़ॉल्ट सीडीएस को हेमेटिक डिप्लॉय JAR में पैकेज किया जाता है.
|
hermetic_srcs
|
लेबल की सूची; |
hermetic_static_libs
|
लेबल की सूची; |
java
|
लेबल; |
java_home
|
स्ट्रिंग; srcs और java एट्रिब्यूट की वैल्यू सबमिट न करें.
|
lib_ct_sym
|
लेबल; --release के साथ कंपाइल करने के लिए, lib/ct.सिम फ़ाइल की ज़रूरत है. अगर इसके बारे में नहीं बताया गया है और
srcs में सिर्फ़ एक ऐसी फ़ाइल है जिसका पाथ
/lib/ct.sym पर खत्म होता है, तो उस फ़ाइल का इस्तेमाल किया जाता है.
|
lib_modules
|
लेबल; |
output_licenses
|
स्ट्रिंग की सूची; |
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_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_opts
|
स्ट्रिंग की सूची; |
android_lint_package_configuration
|
लेबल की सूची; |
android_lint_runner
|
लेबल; |
bootclasspath
|
लेबल की सूची; |
compatible_javacopts
|
null; default is |
deps_checker
|
लेबल; |
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
|
स्ट्रिंग की सूची; |
misc
|
स्ट्रिंग की सूची; |
oneversion
|
लेबल; |
oneversion_allowlist_for_tests
|
लेबल; |
oneversion_whitelist
|
लेबल; |
package_configuration
|
लेबल की सूची; |
proguard_allowlister
|
लेबल; |
reduced_classpath_incompatible_processors
|
स्ट्रिंग की सूची; |
singlejar
|
लेबल; |
source_version
|
स्ट्रिंग; |
target_version
|
स्ट्रिंग; |
timezone_data
|
लेबल; |
tools
|
लेबल की सूची; |
turbine_data
|
लेबल की सूची; |
turbine_jvm_opts
|
स्ट्रिंग की सूची; |
xlint
|
स्ट्रिंग की सूची; |