नियम
- 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 संग्रह ("जार फ़ाइल") बनाता है. साथ ही, नियम के नाम से एक रैपर शेल स्क्रिप्ट भी बनाता है. रैपर शेल स्क्रिप्ट एक ऐसे क्लासपाथ का इस्तेमाल करती है जिसमें दूसरी चीज़ों के अलावा, हर उस लाइब्रेरी के लिए एक जार फ़ाइल शामिल होती है जिस पर बाइनरी निर्भर करती है.
रैपर स्क्रिप्ट कई यूनीक फ़्लैग स्वीकार करती है. रैपर से स्वीकार किए जाने वाले कॉन्फ़िगर किए जा सकने वाले फ़्लैग और एनवायरमेंट वैरिएबल के लिए,
//src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt
देखें.
इंप्लिसिट आउटपुट टारगेट
name.jar
: यह Java संग्रह है, जिसमें क्लास की फ़ाइलें और बाइनरी की डिपेंडेंसी के हिसाब से अन्य संसाधन मौजूद होते हैं.name-src.jar
: ऐसा संग्रह जिसमें सोर्स होते हैं ("सोर्स जार").name_deploy.jar
: जावा संग्रह, डिप्लॉयमेंट के लिए सही है (सिर्फ़ साफ़ तौर पर अनुरोध किए जाने पर ही बनाया जाता है).अपने नियम के लिए
<name>_deploy.jar
टारगेट बनाने पर, मेनिफ़ेस्ट के साथ सेल्फ़-कंटेन्ड जार फ़ाइल बनती है. जार फ़ाइल कोjava -jar
कमांड या रैपर स्क्रिप्ट के--singlejar
विकल्प की मदद से चलाया जा सकता है.java -jar
को रैपर स्क्रिप्ट का इस्तेमाल करने की सलाह दी जाती है, क्योंकि यह JVM फ़्लैग और नेटिव लाइब्रेरी को लोड करने के विकल्प भी पास करती है.डिप्लॉय किए गए जार में वे सभी क्लास शामिल हैं जो उस क्लासलोडर को मिलेंगी जो बाइनरी के रैपर स्क्रिप्ट से शुरू से आखिर तक क्लासपाथ पर खोज करता है. इसमें डिपेंडेंसी के लिए ज़रूरी नेटिव लाइब्रेरी भी शामिल होती हैं. ये रनटाइम के दौरान, जेवीएम में अपने-आप लोड हो जाती हैं.
अगर आपका टारगेट किसी लॉन्चर एट्रिब्यूट के बारे में बताता है, तो सामान्य JAR फ़ाइल के बजाय, _deploy.jar एक नेटिव बाइनरी होगा. इसमें लॉन्चर के साथ-साथ आपके नियम की नेटिव (C++) डिपेंडेंसी भी शामिल होंगी. ये सब एक स्टैटिक बाइनरी से जुड़े होंगे. जार फ़ाइल के बाइट को नेटिव बाइनरी में जोड़ दिया जाएगा. इससे एक बाइनरी ब्लॉब बनता है कि एक्ज़ीक्यूटेबल और Java कोड, दोनों का. जार फ़ाइल को उसी तरह एक्ज़ीक्यूट किया जा सकता है जैसे किसी नेटिव बाइनरी को किया जाता है.
name_deploy-src.jar
: एक संग्रह, जिसमें टारगेट के कुछ समय के लिए बंद किए जाने के आधार पर इकट्ठा किए गए सोर्स शामिल हैं. येdeploy.jar
की क्लास से मेल खाएंगे. हालांकि, उन जगहों को छोड़कर जब जार में मेल खाने वाला कोई सोर्स जार नहीं होता.
srcs
के बिना, java_binary
नियम में deps
एट्रिब्यूट इस्तेमाल करने की अनुमति
नहीं है. इस तरह के नियम के लिए, runtime_deps
के दिए गए
main_class
की ज़रूरत होती है.
यह कोड स्निपेट एक सामान्य गलती दिखाता है:
java_binary( name = "DontDoThis", srcs = [ ...,"GeneratedJavaFile.java"
, # a generated .java file ], deps = [":generating_rule",
], # rule that generates that file )
इसके बजाय यह करें:
java_binary( name = "DoThisInstead", srcs = [ ..., ":generating_rule", ], )
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. सोर्स फ़ाइल के नाम का इस्तेमाल करें. सोर्स फ़ाइल, ऐप्लिकेशन का मुख्य एंट्री पॉइंट है. हालांकि, इसमें एक्सटेंशन शामिल नहीं होता. उदाहरण के लिए, अगर आपके एंट्री पॉइंट को Main.java कहा जाता है, तो आपका नाम Main हो सकता है.
|
deps
|
deps के बारे में की गई सामान्य टिप्पणियां देखें.
|
srcs
|
नियम: अगर नियम (आम तौर पर,
आम तौर पर, इस तर्क की ज़रूरत होती है. हालांकि, अगर |
resources
|
अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य
संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं. |
classpath_resources
|
रिसॉर्स की सूची, जो JavaScript ट्री के रूट में होनी चाहिए. इस एट्रिब्यूट का इस्तेमाल
सिर्फ़ तीसरे पक्ष की लाइब्रेरी के साथ किया जा सकता है. इसके लिए, यह ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर |
create_executable
|
launcher या main_class एट्रिब्यूट को
सेट किया गया है, तो इसे 0 पर सेट करना
गड़बड़ी है.
|
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 प्रोग्राम के लिए.
टारगेट cc_binary होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर,
Java Invocation API को लागू करने वाले किसी भी 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 ) क्लास को Java प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करें. साथ ही, टेस्ट रनर को,
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
: ऐसा संग्रह जिसमें सोर्स होते हैं ("सोर्स जार").
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
deps
|
deps के बारे में की गई सामान्य टिप्पणियां देखें.
वहीं दूसरी ओर, |
srcs
|
नियम: अगर नियम (आम तौर पर,
आम तौर पर, इस तर्क की ज़रूरत होती है. हालांकि, अगर |
data
|
data के बारे में की गई सामान्य टिप्पणियां देखें.
|
resources
|
अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य
संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं. |
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 का भी इस्तेमाल करना चाहता है, तो उसे भी उसे अपने |
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं. |
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
|
रिसॉर्स की सूची, जो JavaScript ट्री के रूट में होनी चाहिए. इस एट्रिब्यूट का इस्तेमाल
सिर्फ़ तीसरे पक्ष की लाइब्रेरी के साथ किया जा सकता है. इसके लिए, यह ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर |
create_executable
|
launcher या main_class एट्रिब्यूट को
सेट किया गया है, तो इसे 0 पर सेट करना
गड़बड़ी है.
|
deploy_manifest_lines
|
*_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट की जगह पर "वैरिएबल बनाएं" लागू नहीं है.
|
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं. |
jvm_flags
|
Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है.
रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, ध्यान दें कि इस एट्रिब्यूट का |
launcher
|
bin/java प्रोग्राम के लिए.
टारगेट cc_binary होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर,
Java Invocation API को लागू करने वाले किसी भी 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
|
स्टैंप वाली बाइनरी को तब तक नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी नहीं बदलतीं. |
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, features, javacopts, licenses, packages, restricted_to, tags, target_compatible_with, testonly, visibility)
पैकेज के सेट पर लागू करने के लिए कॉन्फ़िगरेशन.
कॉन्फ़िगरेशन को
java_toolchain.javacopts
s में जोड़ा जा सकता है.
उदाहरण:
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_plugin
java_plugin(name, deps, srcs, data, resources, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_jars, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, visibility)
java_plugin
, Bazel के ज़रिए चलाए जाने वाले Java कंपाइलर के लिए प्लगिन के बारे में बताता है. फ़िलहाल, एनोटेशन प्रोसेसर ही
सिर्फ़ काम करने वाले प्लगिन के साथ काम करते हैं. java_library
या
java_binary
नियम, plugins
एट्रिब्यूट के ज़रिए प्लगिन के आधार पर उन्हें चला सकता है. java_library
, प्लग इन को
exported_plugins
का इस्तेमाल करके अपने-आप उन लाइब्रेरी में भी एक्सपोर्ट कर सकता है जो
इस पर सीधे तौर पर निर्भर हैं.
इंप्लिसिट आउटपुट टारगेट
libname.jar
: Java संग्रह.
processor_class
तर्क को जोड़े जाने के अलावा, तर्क, java_library
के जैसे ही होते हैं.
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट के लिए एक खास नाम. |
deps
|
deps के बारे में की गई सामान्य टिप्पणियां देखें.
वहीं दूसरी ओर, |
srcs
|
नियम: अगर नियम (आम तौर पर,
आम तौर पर, इस तर्क की ज़रूरत होती है. हालांकि, अगर |
data
|
data के बारे में की गई सामान्य टिप्पणियां देखें.
|
resources
|
अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य
संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं. |
generates_api
|
अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो उस नियम के आधार पर जनरेट किए गए अन्य नियम, जनरेट किए गए कोड को रेफ़र कर सकते हैं. ऐसा तब किया जाता है, जब कंपाइलेशन ऐक्शन, जनरेट करने के नियम के बाद शेड्यूल किया गया हो. यह एट्रिब्यूट, Bazel को --java_header_compilation चालू होने पर शेड्यूल करने से जुड़ी पाबंदियां लागू करने का निर्देश देता है. चेतावनी: इस एट्रिब्यूट से बिल्ड की परफ़ॉर्मेंस पर असर पड़ता है. ज़रूरत होने पर ही इसका इस्तेमाल करें. |
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं. |
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, 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
|
|
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
|
|