नियम
- java_binary
- java_import
- java_library
- java_lite_proto_library
- java_proto_library
- java_test
- java_package_config
- java_प्लग इन
- 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 संग्रह ("jam file&kot;) बनाता है, साथ ही नियम के समान नाम वाली एक रैपर शेल स्क्रिप्ट बनाता है. रैपर शेल स्क्रिप्ट में किसी क्लासपाथ का इस्तेमाल होता है, जिसमें दूसरी लाइब्रेरी के साथ-साथ, हर उस लाइब्रेरी के लिए एक जार फ़ाइल इस्तेमाल होती है जिस पर बाइनरी निर्भर करती है.
रैपर स्क्रिप्ट में कई खास फ़्लैग होते हैं. कॉन्फ़िगर किए जा सकने वाले फ़्लैग और रैपर के स्वीकार किए गए एनवायरमेंट वैरिएबल की सूची के लिए, //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt
देखें.
इंप्लिसिट आउटपुट टारगेट
name.jar
: एक Java संग्रह, जिसमें बाइनरी फ़ाइल और # अन्य संसाधन, बाइनरी और #39; डायरेक्ट डिपेंडेंसी से जुड़े हैं.name-src.jar
: स्रोत वाला संग्रह (&quat;source ja&kot;).name_deploy.jar
: परिनियोजन के लिए सही Java संग्रह (सिर्फ़ खास तौर पर अनुरोध किए जाने पर ही बनाया गया).आपके नियम के लिए
<name>_deploy.jar
टारगेट बनाने पर, मेनिफ़ेस्ट में एक शामिल जार फ़ाइल बन जाती है. इस मेनिफ़ेस्ट कोjava -jar
कमांड या रैपर स्क्रिप्ट या #39;s--singlejar
विकल्प का इस्तेमाल करके चलाने की अनुमति मिलती है.java -jar
के लिए रैपर स्क्रिप्ट का इस्तेमाल करने को प्राथमिकता दी जाती है, क्योंकि यह JVM फ़्लैग और नेटिव लाइब्रेरी लोड करने के विकल्प भी पास करती है.डिप्लॉयमेंट जार में वे सभी क्लास शामिल होती हैं जो क्लासलोडर को मिलती हैं. उसने बाइनरी और #39; रैपर स्क्रिप्ट को शुरुआत से आखिर तक खोजा है. इसमें डिपेंडेंसी के लिए ज़रूरी नेटिव लाइब्रेरी भी शामिल हैं. ये रनटाइम के दौरान, अपने-आप जेवीएम में लोड हो जाते हैं.
अगर आपका टारगेट, लॉन्चर एट्रिब्यूट के बारे में बताता है, तो एक सामान्य JAR फ़ाइल होने के बजाय, _deploy.jam एक नेटिव बाइनरी होगा. इसमें लॉन्चर और साथ ही आपके नियम की सभी नेटिव (C++) डिपेंडेंसी, सभी स्टैटिक बाइनरी से जुड़ी होंगी. असली जार फ़ाइल's बाइट को उस नेटिव बाइनरी में जोड़ दिया जाएगा, जो एक बाइनरी ब्लॉब बनाती है. इसमें एक्ज़ीक्यूटेबल और 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
|
संसाधनों की ऐसी सूची जो जावा के पेड़ के रूट पर मौजूद होनी चाहिए. |
create_executable
|
launcher या main_class एट्रिब्यूट सेट हैं, तो इसे
0 पर सेट करने में गड़बड़ी होती है.
|
deploy_env
|
java_binary टारगेट की सूची, जो इस बाइनरी के लिए डिप्लॉयमेंट एनवायरमेंट को दिखाती हैं.
इस एट्रिब्यूट को ऐसे प्लग इन बनाते समय सेट करें जिसे java_binary
के ज़रिए लोड किया जाएगा.इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉयमेंट जार) की सभी डिपेंडेंसी, इस बाइनरी और deploy_env में बताए गए टारगेट के बीच शेयर नहीं होती.
|
deploy_manifest_lines
|
*_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ी जाने वाली लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट को नहीं "वैरिएबल बनाएं</br>; की जगह लागू करें.
|
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद Javac को पास किए जाते हैं. |
jvm_flags
|
Java बाइनरी की रैपर स्क्रिप्ट में एक classPATH परिभाषा
(सभी निर्भर जार ढूंढने के लिए) शामिल होती है और यह सही Java अनुवादक से संपर्क करती है.
रैपर स्क्रिप्ट से जनरेट किए गए कमांड लाइन में मुख्य क्लास का नाम शामिल होता है. इसके बाद ध्यान रखें कि इस एट्रिब्यूट का |
launcher
|
bin/java प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा.
टारगेट cc_binary होना चाहिए. कोई भी ऐसा cc_binary जो
Java शुरू करने वाला एपीआई लागू करता है, उसे इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है.
डिफ़ॉल्ट रूप से, बेज़ेल सामान्य 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_लाइब्रेरी
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
: स्रोत वाला संग्रह (&quat;source ja&kot;).
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट का एक यूनीक नाम. |
deps
|
deps के बारे में सामान्य टिप्पणियां देखें,
जो सबसे ज़्यादा बनाए गए नियमों के हिसाब से तय
किए गए सामान्य एट्रिब्यूट पर मौजूद हैं.
इसके उलट, |
srcs
|
नियम: अगर नियम (आम तौर पर
इस आर्ग्युमेंट की हमेशा ज़रूरत होती है. हालांकि, |
data
|
data के बारे में सामान्य टिप्पणियां देखें,
जो सबसे ज़्यादा बनाए गए नियमों के हिसाब से तय
किए गए सामान्य एट्रिब्यूट पर मौजूद हैं.
|
resources
|
अगर संसाधन बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य
संसाधन, स्रोत फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं. |
exported_plugins
|
java_plugin की सूची (जैसे कि एनोटेशन प्रोसेसर) जो सीधे तौर पर इस लाइब्रेरी पर निर्भर हैं.
|
exports
|
यहां दिए गए नियमों के मुताबिक, ये पैरंट नियमों के लिए उपलब्ध होंगे. उदाहरण के लिए, ऐसा तब ही होगा, जब अभिभावक साफ़ तौर पर इन नियमों पर निर्भर हों. यह नियम सामान्य (एक्सपोर्ट नहीं किया गया)
खास जानकारी: अगर X कोड के बीच कोई डिपेंडेंसी पाथ है, तो X कोड को ऐक्सेस किया जा सकता है. इसकी शुरुआत
मान लें कि 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_proto_लाइब्रेरी
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_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 फ़ाइल में जोड़ी जाने वाली लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट को नहीं "वैरिएबल बनाएं</br>; की जगह लागू करें.
|
javacopts
|
कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद Javac को पास किए जाते हैं. |
jvm_flags
|
Java बाइनरी की रैपर स्क्रिप्ट में एक classPATH परिभाषा
(सभी निर्भर जार ढूंढने के लिए) शामिल होती है और यह सही Java अनुवादक से संपर्क करती है.
रैपर स्क्रिप्ट से जनरेट किए गए कमांड लाइन में मुख्य क्लास का नाम शामिल होता है. इसके बाद ध्यान रखें कि इस एट्रिब्यूट का |
launcher
|
bin/java प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा.
टारगेट cc_binary होना चाहिए. कोई भी ऐसा cc_binary जो
Java शुरू करने वाला एपीआई लागू करता है, उसे इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है.
डिफ़ॉल्ट रूप से, बेज़ेल सामान्य 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 क्लास का नाम
बताता है. इसे सेट करना बहुत कम है. अगर यह तर्क हटाया जाता है, तो इसका पता लगाने के लिए, टारगेट और #39;
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_प्लग इन
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
बेज़ेल के ज़रिए चलाए गए Java कंपाइलर के प्लग इन बताता है. फ़िलहाल, सिर्फ़ प्रोसेसर की तरह काम करने वाले प्लग इन एनोटेशन प्रोसेसर हैं. java_library
या
java_binary
नियम, plugins
एट्रिब्यूट का इस्तेमाल करके, प्लग इन चला सकता है. java_library
भी प्लग इन को ऐसी लाइब्रेरी में अपने-आप एक्सपोर्ट कर सकता है जिन पर
exported_plugins
का इस्तेमाल करके सीधे तौर पर उन पर निर्भर किया जाता है.
इंप्लिसिट आउटपुट टारगेट
libname.jar
: एक Java संग्रह.
java_library
, आर्ग्युमेंट एक जैसे होते हैं. हालांकि, processor_class
आर्ग्युमेंट जोड़ने के मामले में ऐसा नहीं होता.
तर्क
एट्रिब्यूट | |
---|---|
name |
इस टारगेट का एक यूनीक नाम. |
deps
|
deps के बारे में सामान्य टिप्पणियां देखें,
जो सबसे ज़्यादा बनाए गए नियमों के हिसाब से तय
किए गए सामान्य एट्रिब्यूट पर मौजूद हैं.
इसके उलट, |
srcs
|
नियम: अगर नियम (आम तौर पर
इस आर्ग्युमेंट की हमेशा ज़रूरत होती है. हालांकि, |
data
|
data के बारे में सामान्य टिप्पणियां देखें,
जो सबसे ज़्यादा बनाए गए नियमों के हिसाब से तय
किए गए सामान्य एट्रिब्यूट पर मौजूद हैं.
|
resources
|
अगर संसाधन बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य
संसाधन, स्रोत फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं. |
generates_api
|
अगर कोई नियम एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो दूसरे नियम इस आधार पर जनरेट किए गए कोड का इस्तेमाल कर सकते हैं. ऐसा तभी होगा, जब उन कोड को इकट्ठा करने के नियम, जनरेट करने के नियम के बाद शेड्यूल किए गए हों. यह एट्रिब्यूट, बेजल को निर्देश देता है कि जब --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_रनटाइम
java_runtime(name, srcs, compatible_with, deprecation, distribs, features, hermetic_srcs, java, java_home, lib_modules, licenses, restricted_to, tags, target_compatible_with, testonly, 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
|
|
जैव_टूलचेन
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
|
|