नियम
- 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
: डिप्लॉयमेंट के लिए सही Java संग्रह (सिर्फ़) का अनुरोध किया जाता है).आपके नियम के लिए
<name>_deploy.jar
टारगेट बनाया जा रहा है मेनिफ़ेस्ट के साथ एक सेल्फ़-कंटेन्ड जार फ़ाइल बनाता है, जो इसेjava -jar
निर्देश या रैपर स्क्रिप्ट के--singlejar
की मदद से का विकल्प शामिल है. रैपर स्क्रिप्ट का इस्तेमालjava -jar
के लिए किया जाता है, क्योंकि यह यह JVM फ़्लैग और विकल्पों को भी पास करता है का इस्तेमाल करें.डिप्लॉय जार में वे सभी क्लास शामिल होती हैं जो किसी क्लासलोडर को मिलेंगी बाइनरी के रैपर स्क्रिप्ट से शुरू से आखिर तक क्लासपाथ खोजा. यह भी इसमें डिपेंडेंसी के लिए ज़रूरी नेटिव लाइब्रेरी शामिल हैं. ये अपने-आप लोड हो जाते हैं का इस्तेमाल करने की अनुमति दें.
अगर आपका टारगेट किसी लॉन्चर के बारे में बताता है, तो एट्रिब्यूट का इस्तेमाल करती है, तो सामान्य JAR फ़ाइल होने के बजाय, _Deploy.jar नेटिव बाइनरी. इसमें लॉन्चर और इसकी सभी नेटिव (C++) डिपेंडेंसी शामिल होंगी आपका नियम, सभी एक स्टैटिक बाइनरी से जुड़े हों. जार फ़ाइल की असल बाइट ये होंगी उस नेटिव बाइनरी से जुड़ जाता है, जिससे एक बाइनरी ब्लॉब बनता है जिसमें दोनों और Java कोड भी शामिल है. इसके बाद, जनरेट हुई जार फ़ाइल को सीधे एक्ज़ीक्यूट किया जा सकता है जैसे कि आप किसी भी नेटिव बाइनरी को एक्ज़ीक्यूट करेंगे.
name_deploy-src.jar
: सोर्स वाला एक संग्रह जो टारगेट के अस्थायी तौर पर बंद होने से इकट्ठा की जाती है. ये आपकोdeploy.jar
, जहां जार के पास मिलता-जुलता कोई सोर्स जार नहीं होता है.
java_binary
नियम में deps
विशेषता के बिना अनुमति नहीं है
srcs
; इस तरह के नियम के लिए ज़रूरी है
main_class
इन्होंने दिया
runtime_deps
.
यह कोड स्निपेट एक सामान्य गलती को दिखाता है:
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
|
संसाधनों की एक सूची, जो Java ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट की
इसका मकसद सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी की मदद करना है जिनके लिए ज़रूरी है कि उनके संसाधन
क्लासपाथ पर ठीक |
create_executable
|
launcher या main_class एट्रिब्यूट की वैल्यू सबमिट की जाती है, तो इसे 0 पर सेट किया जाता है
सेट हैं.
|
deploy_env
|
java_binary टारगेट की सूची, जो डिप्लॉयमेंट को दिखाते हैं
नहीं है.
यह एट्रिब्यूट तब सेट करें, जब कोई ऐसा प्लगिन बनाया जाए जिसे किसी दूसरे प्लगिन से लोड किया जाएगा
java_binary .इस एट्रिब्यूट को सेट करने पर, इसमें से सभी डिपेंडेंसी शामिल नहीं होती हैं इसके बीच शेयर की गई इस बाइनरी का रनटाइम क्लासपाथ (और डिप्लॉय जार) बाइनरी और deploy_env में बताए गए टारगेट.
|
deploy_manifest_lines
|
META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची,
*_deploy.jar का टारगेट. इस एट्रिब्यूट के कॉन्टेंट का विषय नहीं है
"वैरिएबल बनाएं" के विकल्प का इस्तेमाल करें.
|
javacopts
|
ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं. |
jvm_flags
|
Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है
(सभी डिपेंडेंट जार ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करता है.
रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में
मुख्य क्लास के बाद ध्यान दें कि इस एट्रिब्यूट का |
launcher
|
bin/java प्रोग्राम.
टारगेट cc_binary होना चाहिए. कोई cc_binary
लागू करता है:
Java इनवोकेशन एपीआई को इस एट्रिब्यूट की वैल्यू के तौर पर सेट किया जा सकता है.
डिफ़ॉल्ट रूप से, Basel सामान्य 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)
इस नियम के तहत, पहले से कंपाइल की गई .jar
फ़ाइलों का इस्तेमाल इस तरह किया जा सकता है:
java_library
और
java_binary
नियम.
उदाहरण
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 पर चलने वाली किसी भी चीज़ के लिए
एक स्टैंडर्ड JDK शामिल है.
|
proguard_specs
|
android_binary टारगेट में जोड़ दिया जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ पहचान बदलने वाले नियम होने चाहिए, जैसे कि -dontnote, -dontvarn,
माना जाता है कि -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 हैं
पर चलाना चाहते हैं.
ध्यान दें कि अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि में अंतर सिर्फ़ उन जगहों पर होता है जहां JLS, कंपाइलर को इनलाइन जाने से रोकता है (और जो आने वाले समय में लॉन्च की जाएगी. |
plugins
|
java_plugin , जब भी यह नियम लागू होगा, तब ट्रिगर की जाएगी
बनाया जाता है. कोई लाइब्रेरी उन डिपेंडेंसी से प्लगिन भी इनहेरिट कर सकती है जिनका इस्तेमाल किया जाता है
exported_plugins . रिसोर्स
प्लगिन से जनरेट की गई वैल्यू को इस नियम के नतीजे में मिलने वाले जार में शामिल किया जाएगा.
|
proguard_specs
|
android_binary टारगेट में जोड़ दिया जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ पहचान बदलने वाले नियम होने चाहिए, जैसे कि -dontnote, -dontvarn,
माना जाता है कि -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_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_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 संग्रह के लिए सही है डिप्लॉयमेंट के लिए. (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो.) हर पेज के लिएname_deploy.jar
आउटपुट java_binary पर क्लिक करें.
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
|
संसाधनों की एक सूची, जो Java ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट की
इसका मकसद सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी की मदद करना है जिनके लिए ज़रूरी है कि उनके संसाधन
क्लासपाथ पर ठीक |
create_executable
|
launcher या main_class एट्रिब्यूट की वैल्यू सबमिट की जाती है, तो इसे 0 पर सेट किया जाता है
सेट हैं.
|
deploy_manifest_lines
|
META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची,
*_deploy.jar का टारगेट. इस एट्रिब्यूट के कॉन्टेंट का विषय नहीं है
"वैरिएबल बनाएं" के विकल्प का इस्तेमाल करें.
|
javacopts
|
ग्लोबल कंपाइलर विकल्पों के बाद, ये कंपाइलर विकल्प javac को पास किए जाते हैं. |
jvm_flags
|
Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है
(सभी डिपेंडेंट जार ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करता है.
रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में
मुख्य क्लास के बाद ध्यान दें कि इस एट्रिब्यूट का |
launcher
|
bin/java प्रोग्राम.
टारगेट cc_binary होना चाहिए. कोई cc_binary
लागू करता है:
Java इनवोकेशन एपीआई को इस एट्रिब्यूट की वैल्यू के तौर पर सेट किया जा सकता है.
डिफ़ॉल्ट रूप से, Basel सामान्य 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
.
उदाहरण:
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
, Basel के चलाए जा रहे 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 हैं
पर चलाना चाहते हैं.
ध्यान दें कि अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि में अंतर सिर्फ़ उन जगहों पर होता है जहां JLS, कंपाइलर को इनलाइन जाने से रोकता है (और जो आने वाले समय में लॉन्च की जाएगी. |
output_licenses
|
common attributes
देखें
|
plugins
|
java_plugin , जब भी यह नियम लागू होगा, तब ट्रिगर की जाएगी
बनाया जाता है. कोई लाइब्रेरी उन डिपेंडेंसी से प्लगिन भी इनहेरिट कर सकती है जिनका इस्तेमाल किया जाता है
exported_plugins . रिसोर्स
प्लगिन से जनरेट की गई वैल्यू को इस नियम के नतीजे में मिलने वाले जार में शामिल किया जाएगा.
|
processor_class
|
|
proguard_specs
|
android_binary टारगेट में जोड़ दिया जाएगा.
यहां शामिल की गई फ़ाइलों में सिर्फ़ पहचान बदलने वाले नियम होने चाहिए, जैसे कि -dontnote, -dontvarn,
माना जाता है कि -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
|
|