इस पेज में ऐसे संसाधन हैं जो आपको Java प्रोजेक्ट के साथ Baज़ल का इस्तेमाल करने में मदद करते हैं. यह किसी ट्यूटोरियल, नियम बनाने, और अन्य जानकारी के लिए लिंक Basel के साथ Java प्रोजेक्ट.
बेज़ल के साथ काम करना
नीचे दिए गए संसाधन, आपको Java प्रोजेक्ट पर Bagel के साथ काम करने में मदद करेंगे:
बेज़ल पर माइग्रेट किया जा रहा है
अगर आपने फ़िलहाल Maven की मदद से अपने Java प्रोजेक्ट बनाए हैं, तो यहां दिया गया तरीका अपनाएं Basel की मदद से, Maven प्रोजेक्ट बनाने के लिए माइग्रेशन गाइड:
Java वर्शन
कॉन्फ़िगरेशन फ़्लैग के साथ सेट किए गए Java के दो सही वर्शन हैं:
- डेटा स्टोर करने की जगह में सोर्स फ़ाइलों का वर्शन
- यह Java रनटाइम का वर्शन होता है. इसका इस्तेमाल, कोड को एक्ज़ीक्यूट करने और उसकी जांच करने के लिए किया जाता है यह
डेटा स्टोर करने की जगह में सोर्स कोड का वर्शन कॉन्फ़िगर करना
किसी अतिरिक्त कॉन्फ़िगरेशन के बिना, Basel,
डेटा स्टोर करने की जगह को एक ही Java वर्शन में लिखा जाता है. इसका वर्शन तय करने के लिए
रिपॉज़िटरी में मौजूद सोर्स में build --java_language_version={ver}
को जोड़ें
.bazelrc
फ़ाइल, जहां {ver}
है, उदाहरण के लिए 11
. बेज़ल रिपॉज़िटरी के मालिक
को यह फ़्लैग सेट करना चाहिए ताकि बेज़ेल और उसके उपयोगकर्ता स्रोत कोड
Java का वर्शन नंबर. ज़्यादा जानकारी के लिए, यह देखें
Java की भाषा के लिए वर्शन फ़्लैग.
कोड को एक्ज़ीक्यूट करने और उसकी जांच करने के लिए इस्तेमाल की जाने वाली जेवीएम को कॉन्फ़िगर करना
Basel, कंपाइलेशन के लिए एक JDK और दूसरे JVM का इस्तेमाल करके, कोड को एक्ज़ीक्यूट और टेस्ट करता है.
डिफ़ॉल्ट रूप से Basel एक JDK का इस्तेमाल करके कोड को कंपाइल करता है, वह डाउनलोड होता है और एक्ज़ीक्यूट करता है
यह लोकल मशीन पर इंस्टॉल किए गए JVM की मदद से, कोड की जाँच करता है. बेज़ेल ने खोजा
JAVA_HOME
या पाथ का इस्तेमाल करके JVM.
इससे बनने वाली बाइनरी, सिस्टम में लोकल लेवल पर इंस्टॉल की गई JVM के साथ काम करती हैं लाइब्रेरी का इस्तेमाल किया जाता है, जिसका मतलब है कि बनने वाली बाइनरी इस बात पर निर्भर करती हैं कि लाइब्रेरी में क्या इंस्टॉल किया गया है मशीन.
एक्ज़ीक्यूशन और टेस्ट करने के लिए इस्तेमाल किए जाने वाले JVM को कॉन्फ़िगर करने के लिए, --java_runtime_version
का इस्तेमाल करें
फ़्लैग करें. डिफ़ॉल्ट वैल्यू local_jdk
है.
हर्मेटिक टेस्टिंग और कंपाइलेशन
हर्मेटिक कंपाइल बनाने के लिए, कमांड लाइन फ़्लैग का इस्तेमाल करें
--java_runtime_version=remotejdk_11
. कोड को इन कामों के लिए कंपाइल किया जाता है, एक्ज़ीक्यूट किया जाता है, और
रिमोट रिपॉज़िटरी से डाउनलोड किए गए JVM पर टेस्ट किया गया. ज़्यादा जानकारी के लिए, यह देखें
Java रनटाइम वर्शन फ़्लैग.
Java में बिल्ड टूल को कंपाइल करने और उसे एक्ज़ीक्यूट करने के लिए कॉन्फ़िगर करना
JDK और JVM की दूसरी जोड़ी का इस्तेमाल, टूल बनाने और उन्हें लागू करने के लिए किया जाता है. ये
का इस्तेमाल बिल्ड प्रोसेस में किया गया है, लेकिन इनका इस्तेमाल बिल्ड के नतीजों में नहीं किया गया है. वह JDK और JVM
इन्हें --tool_java_language_version
का इस्तेमाल करके कंट्रोल किया जाता है और
--tool_java_runtime_version
. डिफ़ॉल्ट वैल्यू 11
और remotejdk_11
हैं.
क्रम से.
स्थानीय तौर पर इंस्टॉल किए गए JDK का इस्तेमाल करके कंपाइल किया जा रहा है
डिफ़ॉल्ट रूप से Basel, रिमोट JDK का इस्तेमाल करके कंपाइल करता है, क्योंकि यह JDK की अंदरूनी. स्थानीय तौर पर इंस्टॉल किए गए JDK का इस्तेमाल करने वाले कंपाइलेशन टूलचेन को कॉन्फ़िगर किया गया है, हालाँकि, उसका इस्तेमाल नहीं किया जाता.
स्थानीय तौर पर इंस्टॉल किए गए JDK का इस्तेमाल करके कंपाइल करने के लिए, यह कंपाइलेशन टूलचेन का इस्तेमाल करता है
स्थानीय JDK के लिए, अतिरिक्त फ़्लैग --extra_toolchains=@local_jdk//:all
का उपयोग करें,
हालांकि, हो सकता है कि यह आर्बिट्रेरी वेंडर के JDK पर काम न करे.
ज़्यादा जानकारी के लिए, यह देखें Java टूल चेन कॉन्फ़िगर करना.
सबसे सही तरीके
बेज़ल से जुड़े सबसे सही सामान्य तरीकों के अलावा, यहां दिए गए हैं Java प्रोजेक्ट के लिए सबसे सही तरीके.
डायरेक्ट्री स्ट्रक्चर
Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को प्राथमिकता दें (src/main/java
में मौजूद सोर्स, जांच करें)
src/test/java
से कम).
फ़ाइलें बनाएं
अपनी BUILD
फ़ाइलें बनाते समय इन दिशा-निर्देशों का पालन करें:
Java सोर्स वाली हर डायरेक्ट्री के लिए, एक
BUILD
फ़ाइल का इस्तेमाल करें, क्योंकि यह बिल्ड की परफ़ॉर्मेंस को बेहतर बनाता है.हर
BUILD
फ़ाइल में एकjava_library
नियम होना चाहिए, जो ऐसा दिखता है शामिल करें:java_library( name = "directory-name", srcs = glob(["*.java"]), deps = [...], )
लाइब्रेरी का नाम उस डायरेक्ट्री का नाम होना चाहिए जिसमें
BUILD
फ़ाइल. इससे लाइब्रेरी का लेबल छोटा हो जाता है,"//package:package"
के बजाय"//package"
.सोर्स ऐसा होना चाहिए जो बार-बार न आए
glob
सभी Java फ़ाइलें शामिल होनी चाहिए.टेस्ट,
src/test
से मिलती-जुलती डायरेक्ट्री में होने चाहिए और इस पर निर्भर होने चाहिए लाइब्रेरी.
बेहतर Java बिल्ड के लिए नए नियम बनाना
ध्यान दें: नए नियम, बेहतर बिल्ड और टेस्ट स्थितियों के लिए हैं. आप करें बेज़ल के साथ शुरू करते समय इसकी ज़रूरत नहीं है.
नीचे दिए गए मॉड्यूल, कॉन्फ़िगरेशन फ़्रैगमेंट, और सेवा देने वाली कंपनियां आपकी मदद करेंगी अपना Java बनाते समय Basel की सुविधाओं को बढ़ाएं प्रोजेक्ट:
- मुख्य Java की सेवा देने वाली कंपनी:
java_common
- मुख्य Java मॉड्यूल:
JavaInfo
- कॉन्फ़िगरेशन का हिस्सा:
java
अन्य मॉड्यूल:
Java टूलचेन कॉन्फ़िगर करना
Baज़र, दो तरह के Java टूलचेन का इस्तेमाल करता है:
- निष्पादन, जावा बाइनरी को निष्पादित और परीक्षण करने के लिए उपयोग किया जाता है,
--java_runtime_version
फ़्लैग
- कंपाइलेशन, जिसका इस्तेमाल Java सोर्स को कंपाइल करने में किया जाता है. साथ ही, इसे
--java_language_version
फ़्लैग
अतिरिक्त निष्पादन टूलचेन कॉन्फ़िगर करना
एक्ज़ीक्यूशन टूलचेन एक JVM है. यह या तो लोकल या रिपॉज़िटरी से होता है. इसमें कुछ इस ऐप्लिकेशन के वर्शन, ऑपरेटिंग सिस्टम, और सीपीयू के बारे में अतिरिक्त जानकारी आर्किटेक्चर.
Java को एक्ज़ीक्यूट करने के टूलचेन local_java_repository
का इस्तेमाल करके जोड़े जा सकते हैं या
WORKSPACE
फ़ाइल में remote_java_repository
नियम. नियम जोड़ने से यह बनता है
फ़्लैग का इस्तेमाल करके JVM उपलब्ध कराया जा सकता है. जब एक ही ऑपरेटिंग के लिए कई परिभाषाएं
सिस्टम और सीपीयू आर्किटेक्चर दिए गए हैं, पहले वाले का इस्तेमाल किया गया है.
लोकल JVM कॉन्फ़िगरेशन का उदाहरण:
load("@bazel_tools//tools/jdk:local_java_repository.bzl", "local_java_repository")
local_java_repository(
name = "additionaljdk", # Can be used with --java_runtime_version=additionaljdk, --java_runtime_version=11 or --java_runtime_version=additionaljdk_11
version = 11, # Optional, if not set it is autodetected
java_home = "/usr/lib/jdk-15/", # Path to directory containing bin/java
)
रिमोट जेवीएम के कॉन्फ़िगरेशन का उदाहरण:
load("@bazel_tools//tools/jdk:remote_java_repository.bzl", "remote_java_repository")
remote_java_repository(
name = "openjdk_canary_linux_arm",
prefix = "openjdk_canary", # Can be used with --java_runtime_version=openjdk_canary_11
version = "11", # or --java_runtime_version=11
target_compatible_with = [ # Specifies constraints this JVM is compatible with "@platforms//cpu:arm",
"@platforms//os:linux",
],
urls = ..., # Other parameters are from http_repository rule.
sha256 = ...,
strip_prefix = ...
)
अतिरिक्त कंपाइलेशन टूलचेन कॉन्फ़िगर करना
कंपाइलेशन टूलचेन, JDK और ऐसे कई टूल से मिलकर बना है जिन्हें Basel ने इस्तेमाल किया है कंपाइलेशन के दौरान दिखाया गया हो और अतिरिक्त सुविधाएं दी गई हों, जैसे: प्रोन, सख्त Java डिपेंडेंसी, हेडर कंपाइलेशन, Android डिसुगरिंग, कवरेज इंस्ट्रुमेंटेशन, और IDEs के लिए genclass की हैंडलिंग.
JavaBuilder, Basel से जुड़ा एक टूल है. यह कंपाइलेशन लागू करता है, और
सुविधाओं के बारे में जानकारी मिलेगी. असल कंपाइलेशन को अंदरूनी
इसे जेडीके ने कंपाइल किया है. कंपाइलेशन के लिए इस्तेमाल किए जाने वाले JDK की जानकारी java_runtime
ने दी है
एट्रिब्यूट की वैल्यू शामिल होती है.
Baज़ल, JDK इंंटरनल को बदल देता है. JDK वर्शन के मामले में > 9,
java.compiler
और jdk.compiler
मॉड्यूल को JDK के फ़्लैग का इस्तेमाल करके पैच किया गया है
--patch_module
. JDK वर्शन 8 के मामले में, Java कंपाइलर को
-Xbootclasspath
फ़्लैग.
VenillaJavaBuilder, Javaबिल्डर को लागू करने की दूसरी प्रोसेस है. जो JDK के इंटरनल कंपाइलर में बदलाव नहीं करता और न ही अतिरिक्त सुविधाएं. वनिलाJava बिल्डर का इस्तेमाल किसी भी बिल्ट-इन सुविधा के लिए नहीं किया गया है टूलचेन.
JavaBuilder के अलावा, Basel, कंपाइलेशन के दौरान कई अन्य टूल का इस्तेमाल करता है.
ijar
टूल, कॉल को छोड़कर बाकी सब कुछ हटाने के लिए jar
फ़ाइलों को प्रोसेस करता है
हस्ताक्षर. नतीजे में मिलने वाले जार को हेडर जार कहा जाता है. उनका इस्तेमाल
डाउनस्ट्रीम डिपेंडेंट्स को फिर से कंपाइल करके, कंपाइलेशन प्रोग्रैम्ड को तब ज़्यादा करें, जब
किसी फ़ंक्शन का मुख्य हिस्सा बदल जाता है.
singlejar
टूल की मदद से, कई jar
फ़ाइलों को एक ही फ़ोल्डर में पैक किया जा सकता है.
genclass
टूल, Java कंपाइलेशन के आउटपुट को प्रोसेस करने के बाद प्रोसेस करता है और
एक jar
जिसमें सिर्फ़ उन सोर्स की क्लास फ़ाइलें हैं जिन्हें इसके ज़रिए जनरेट किया गया था
एनोटेशन प्रोसेसर.
JacocoRunner
टूल, Jacoco को इंस्ट्रुमेंट की गई फ़ाइलों पर रन करता है और आउटपुट के नतीजे दिखाता है
LCOV फ़ॉर्मैट में डालें.
TestRunner
टूल, JUnit 4 के टेस्ट को कंट्रोल किए गए एनवायरमेंट में लागू करता है.
default_java_toolchain
मैक्रो को जोड़कर, कंपाइलेशन को फिर से कॉन्फ़िगर किया जा सकता है
एक BUILD
फ़ाइल बनाई हो और इसमें register_toolchains
नियम जोड़कर उसे रजिस्टर किया जा रहा हो
WORKSPACE
फ़ाइल या
--extra_toolchains
फ़्लैग.
टूलचेन का इस्तेमाल सिर्फ़ तब किया जाता है, जब source_version
एट्रिब्यूट
--java_language_version
फ़्लैग के ज़रिए तय किया गया मान.
टूलचेन कॉन्फ़िगरेशन का उदाहरण:
load(
"@bazel_tools//tools/jdk:default_java_toolchain.bzl",
"default_java_toolchain", "DEFAULT_TOOLCHAIN_CONFIGURATION", "BASE_JDK9_JVM_OPTS", "DEFAULT_JAVACOPTS"
)
default_java_toolchain(
name = "repository_default_toolchain",
configuration = DEFAULT_TOOLCHAIN_CONFIGURATION, # One of predefined configurations
# Other parameters are from java_toolchain rule:
java_runtime = "@bazel_tools//tools/jdk:remote_jdk11", # JDK to use for compilation and toolchain's tools execution
jvm_opts = BASE_JDK9_JVM_OPTS + ["--enable_preview"], # Additional JDK options
javacopts = DEFAULT_JAVACOPTS + ["--enable_preview"], # Additional javac options
source_version = "9",
)
जिसे --extra_toolchains=//:repository_default_toolchain_definition
का इस्तेमाल करके इस्तेमाल किया जा सकता है
या register_toolchains("//:repository_default_toolchain_definition")
जोड़कर
काम की रफ़्तार पर फ़ोकस कर सकते हैं.
पहले से तय कॉन्फ़िगरेशन:
DEFAULT_TOOLCHAIN_CONFIGURATION
: सभी सुविधाएं, JDK वर्शन >= 9 पर काम करती हैंVANILLA_TOOLCHAIN_CONFIGURATION
: कोई अतिरिक्त सुविधा नहीं, के JDK का समर्थन करते हैं आर्बिट्रेरी वेंडर.PREBUILT_TOOLCHAIN_CONFIGURATION
: डिफ़ॉल्ट के जैसा ही है, लेकिन सिर्फ़ पहले से बने हुए का इस्तेमाल करें टूल (ijar
,singlejar
)NONPREBUILT_TOOLCHAIN_CONFIGURATION
: डिफ़ॉल्ट की तरह ही, लेकिन सभी टूल (यह अलग-अलग ऑपरेटिंग सिस्टम के साथ काम करने वाले ऑपरेटिंग सिस्टम पर लिबसी)
JVM और Java कंपाइलर फ़्लैग कॉन्फ़िगर करना
JVM और javac फ़्लैग को फ़्लैग या
default_java_toolchain
एट्रिब्यूट.
सही फ़्लैग --jvmopt
, --host_jvmopt
, --javacopt
, और हैं
--host_javacopt
.
काम के default_java_toolchain
एट्रिब्यूट ये हैं: javacopts
, jvm_opts
,
javabuilder_jvm_opts
और turbine_jvm_opts
.
पैकेज के हिसाब से Java कंपाइलर फ़्लैग कॉन्फ़िगरेशन
किसी खास सोर्स के लिए अलग-अलग Java कंपाइलर फ़्लैग कॉन्फ़िगर किए जा सकते हैं
default_java_toolchain
के package_configuration
एट्रिब्यूट का इस्तेमाल करने वाली फ़ाइलें.
कृपया नीचे दिया गया उदाहरण देखें.
load("@bazel_tools//tools/jdk:default_java_toolchain.bzl", "default_java_toolchain")
# This is a convenience macro that inherits values from Bazel's default java_toolchain
default_java_toolchain(
name = "toolchain",
package_configuration = [
":error_prone",
],
visibility = ["//visibility:public"],
)
# This associates a set of javac flags with a set of packages
java_package_configuration(
name = "error_prone",
javacopts = [
"-Xep:MissingOverride:ERROR",
],
packages = ["error_prone_packages"],
)
# This is a regular package_group, which is used to specify a set of packages to apply flags to
package_group(
name = "error_prone_packages",
packages = [
"//foo/...",
"-//foo/bar/...", # this is an exclusion
],
)
एक ही रिपॉज़िटरी में Java सोर्स कोड के कई वर्शन
Baज़ल, किसी बिल्ड में Java सोर्स के सिर्फ़ एक वर्शन को कंपाइल करने की सुविधा देता है. बिल्ड. इसका मतलब है कि Java परीक्षण या कोई ऐप्लिकेशन बनाते समय, सभी डिपेंडेंसी एक ही Java वर्शन पर बनाई गई हैं.
हालांकि, अलग-अलग फ़्लैग का इस्तेमाल करके अलग-अलग बिल्ड चलाए जा सकते हैं.
अलग-अलग फ़्लैग के इस्तेमाल को आसान बनाने के लिए, फ़्लैग के सेट
वर्शन को .bazelrc
कॉन्फ़िगरेशन के साथ ग्रुप किया जा सकता है:
build:java8 --java_language_version=8
build:java8 --java_runtime_version=localjdk_8
build:java11 --java_language_version=11
build:java11 --java_runtime_version=remotejdk_11
इन कॉन्फ़िगरेशन का इस्तेमाल, --config
फ़्लैग के साथ किया जा सकता है, उदाहरण के लिए
bazel test --config=java11 //:java11_test
.