इस पेज पर ऐसे संसाधन मौजूद हैं जिनकी मदद से, Java प्रोजेक्ट के साथ Bazel का इस्तेमाल किया जा सकता है. इसमें एक ट्यूटोरियल, बिल्ड के नियम, और Bazel की मदद से Java प्रोजेक्ट बनाने से जुड़ी अन्य जानकारी शामिल है.
Bazel का इस्तेमाल करना
Java प्रोजेक्ट पर Bazel का इस्तेमाल करने के लिए, इन संसाधनों की मदद लें:
Bazel पर माइग्रेट करना
अगर फ़िलहाल, Java प्रोजेक्ट बनाने के लिए Maven का इस्तेमाल किया जाता है, तो माइग्रेशन गाइड में दिए गए चरणों को पूरा करके, Maven प्रोजेक्ट बनाने के लिए Bazel का इस्तेमाल करें:
Java के वर्शन
Java के दो वर्शन काम के हैं. इन्हें कॉन्फ़िगरेशन फ़्लैग की मदद से सेट किया जाता है:
- डेटाबेस में मौजूद सोर्स फ़ाइलों का वर्शन
- Java रनटाइम का वर्शन, जिसका इस्तेमाल कोड को चलाने और उसकी जांच करने के लिए किया जाता है
अपने डेटाबेस में मौजूद सोर्स कोड का वर्शन कॉन्फ़िगर करना
कोई अन्य कॉन्फ़िगरेशन न होने पर, Bazel यह मान लेता है कि डेटाबेस में मौजूद सभी Java सोर्स फ़ाइलें, Java के एक ही वर्शन में लिखी गई हैं. डेटाबेस में मौजूद
सोर्स का वर्शन तय करने के लिए, build --java_language_version={ver} को
.bazelrc फ़ाइल में जोड़ें. यहां {ver} का मतलब, उदाहरण के लिए 11 है. Bazel के डेटाबेस के मालिकों को यह फ़्लैग सेट करना चाहिए, ताकि Bazel और उसके उपयोगकर्ता, सोर्स कोड के Java वर्शन नंबर को रेफ़र कर सकें. ज़्यादा जानकारी के लिए, Java लैंग्वेज वर्शन फ़्लैग देखें.
कोड को चलाने और उसकी जांच करने के लिए इस्तेमाल किए जाने वाले जेवीएम को कॉन्फ़िगर करना
Bazel, कंपाइलेशन के लिए एक जेडीके और कोड को चलाने और उसकी जांच करने के लिए दूसरा जेवीएम इस्तेमाल करता है.
डिफ़ॉल्ट रूप से, Bazel, कोड को कंपाइल करने के लिए डाउनलोड किए गए जेडीके का इस्तेमाल करता है. साथ ही, यह कोड को चलाने और उसकी जांच करने के लिए, लोकल मशीन पर इंस्टॉल किए गए जेवीएम का इस्तेमाल करता है. Bazel, जेवीएम को खोजने के लिए JAVA_HOME या पाथ का इस्तेमाल करता है.
इससे बनने वाली बाइनरी, सिस्टम लाइब्रेरी में स्थानीय तौर पर इंस्टॉल किए गए जेवीएम के साथ काम करती हैं. इसका मतलब है कि इससे बनने वाली बाइनरी, मशीन पर इंस्टॉल किए गए सॉफ़्टवेयर पर निर्भर करती हैं.
कोड को चलाने और उसकी जांच करने के लिए इस्तेमाल किए जाने वाले जेवीएम को कॉन्फ़िगर करने के लिए, --java_runtime_version फ़्लैग का इस्तेमाल करें. डिफ़ॉल्ट वैल्यू local_jdk है.
हर्मेटिक टेस्टिंग और कंपाइलेशन
हर्मेटिक कंपाइल बनाने के लिए, कमांड लाइन फ़्लैग --java_runtime_version=remotejdk_11 का इस्तेमाल किया जा सकता है. कोड को, रिमोट डेटाबेस से डाउनलोड किए गए जेवीएम पर कंपाइल, चलाया, और टेस्ट किया जाता है. ज़्यादा जानकारी के लिए, Java रनटाइम वर्शन फ़्लैग देखें.
Java में बिल्ड टूल के कंपाइलेशन और एक्ज़ीक्यूशन को कॉन्फ़िगर करना
जेडीके और जेवीएम का एक और पेयर है, जिसका इस्तेमाल टूल बनाने और उन्हें चलाने के लिए किया जाता है. इनका इस्तेमाल बिल्ड प्रोसेस में किया जाता है, लेकिन ये बिल्ड के नतीजों में शामिल नहीं होते. इन जेडीके और जेवीएम को --tool_java_language_version और --tool_java_runtime_version का इस्तेमाल करके कंट्रोल किया जाता है. डिफ़ॉल्ट वैल्यू, क्रमशः 11 और remotejdk_11,
हैं.
स्थानीय तौर पर इंस्टॉल किए गए जेडीके का इस्तेमाल करके कंपाइल करना
Bazel, डिफ़ॉल्ट रूप से रिमोट जेडीके का इस्तेमाल करके कंपाइल करता है, क्योंकि यह जेडीके के इंटरनल को बदलता है. स्थानीय तौर पर इंस्टॉल किए गए जेडीके का इस्तेमाल करके कंपाइलेशन टूलचेन को कॉन्फ़िगर किया जाता है. हालांकि, इनका इस्तेमाल नहीं किया जाता.
स्थानीय तौर पर इंस्टॉल किए गए जेडीके का इस्तेमाल करके कंपाइल करने के लिए, यानी स्थानीय जेडीके के लिए कंपाइलेशन टूलचेन का इस्तेमाल करने के लिए, --extra_toolchains=@local_jdk//:all फ़्लैग का इस्तेमाल करें. हालांकि, ध्यान रखें कि यह किसी भी वेंडर के जेडीके पर काम नहीं कर सकता है.
ज़्यादा जानकारी के लिए, Java टूलचेन को कॉन्फ़िगर करना लेख पढ़ें.
सबसे सही तरीके
Bazel के सामान्य सबसे सही तरीकों के अलावा, यहां Java प्रोजेक्ट के लिए सबसे सही तरीके दिए गए हैं.
डायरेक्ट्री स्ट्रक्चर
Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (सोर्स, src/main/java में और टेस्ट, src/test/java में) का इस्तेमाल करें.
BUILD फ़ाइलें
BUILD फ़ाइलें बनाते समय इन दिशा-निर्देशों का पालन करें:
Java सोर्स वाली हर डायरेक्ट्री के लिए, एक
BUILDफ़ाइल का इस्तेमाल करें. इससे बिल्ड की परफ़ॉर्मेंस बेहतर होती है.हर
BUILDफ़ाइल में,java_libraryका एक नियम होना चाहिए. यह नियम ऐसा दिखता है:java_library( name = "directory-name", srcs = glob(["*.java"]), deps = [...], )लाइब्रेरी का नाम,
BUILDफ़ाइल वाली डायरेक्ट्री का नाम होना चाहिए. इससे लाइब्रेरी का लेबल छोटा हो जाता है. जैसे,"//package:package"के बजाय"//package"का इस्तेमाल करें.सोर्स, डायरेक्ट्री में मौजूद सभी Java फ़ाइलों का नॉन-रिकर्सिव
globof होना चाहिए.टेस्ट,
src/testमें मैचिंग डायरेक्ट्री में होने चाहिए और इस लाइब्रेरी पर निर्भर होने चाहिए.
ऐडवांस Java बिल्ड के लिए नए नियम बनाना
ध्यान दें: नए नियम, ऐडवांस बिल्ड और टेस्ट के लिए बनाए जाते हैं. Bazel का इस्तेमाल शुरू करने के लिए, इनकी ज़रूरत नहीं होती.
- मुख्य Java मॉड्यूल:
java_common - मुख्य Java प्रोवाइडर:
JavaInfo - कॉन्फ़िगरेशन फ़्रैगमेंट:
java अन्य मॉड्यूल:
Java टूलचेन को कॉन्फ़िगर करना
Bazel, दो तरह के Java टूलचेन का इस्तेमाल करता है:
- एक्ज़ीक्यूशन, जिसका इस्तेमाल Java बाइनरी को चलाने और उसकी जांच करने के लिए किया जाता है. इसे
--java_runtime_version फ़्लैग से कंट्रोल किया जाता है
- कंपाइलेशन, जिसका इस्तेमाल Java सोर्स को कंपाइल करने के लिए किया जाता है. इसे
--java_language_version फ़्लैग से कंट्रोल किया जाता है
अन्य एक्ज़ीक्यूशन टूलचेन को कॉन्फ़िगर करना
एक्ज़ीक्यूशन टूलचेन, जेवीएम होता है. यह जेवीएम, लोकल या डेटाबेस से लिया जा सकता है. इसमें इसके वर्शन, ऑपरेटिंग सिस्टम, और सीपीयू आर्किटेक्चर के बारे में कुछ अतिरिक्त जानकारी होती है.
Java एक्ज़ीक्यूशन टूलचेन को, मॉड्यूल एक्सटेंशन में local_java_repository या remote_java_repository रेपो नियमों का इस्तेमाल करके जोड़ा जा सकता है. नियम जोड़ने से, जेवीएम को फ़्लैग का इस्तेमाल करके उपलब्ध कराया जा सकता है. जब एक ही ऑपरेटिंग सिस्टम और सीपीयू आर्किटेक्चर के लिए कई परिभाषाएं दी जाती हैं, तो पहली परिभाषा का इस्तेमाल किया जाता है.
लोकल जेवीएम के कॉन्फ़िगरेशन का उदाहरण:
load("@rules_java//toolchains: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("@rules_java//toolchains: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 = ...
)
अन्य कंपाइलेशन टूलचेन को कॉन्फ़िगर करना
कंपाइलेशन टूलचेन में जेडीके और कई टूल शामिल होते हैं. Bazel, कंपाइलेशन के दौरान इनका इस्तेमाल करता है. साथ ही, यह Error Prone, सख्त Java डिपेंडेंसी, हेडर कंपाइलेशन, Android desugaring, कवरेज इंस्ट्रूमेंटेशन, और IDE के लिए genclass हैंडलिंग जैसी अतिरिक्त सुविधाएं उपलब्ध कराता है.
JavaBuilder, Bazel के साथ बंडल किया गया एक टूल है. यह कंपाइलेशन को एक्ज़ीक्यूट करता है और ऊपर बताई गई सुविधाएं उपलब्ध कराता है. असल कंपाइलेशन, जेडीके के इंटरनल कंपाइलर का इस्तेमाल करके एक्ज़ीक्यूट किया जाता है. कंपाइलेशन के लिए इस्तेमाल किए जाने वाले जेडीके को, टूलचेन के java_runtime एट्रिब्यूट से तय किया जाता है.
Bazel, जेडीके के कुछ इंटरनल को बदलता है. जेडीके के वर्शन > 9 होने पर, java.compiler और jdk.compiler मॉड्यूल को, जेडीके के फ़्लैग --patch_module का इस्तेमाल करके पैच किया जाता है. जेडीके के वर्शन 8 होने पर, Java कंपाइलर को -Xbootclasspath फ़्लैग का इस्तेमाल करके पैच किया जाता है.
VanillaJavaBuilder, JavaBuilder का दूसरा इंप्लीमेंटेशन है. यह जेडीके के इंटरनल कंपाइलर में बदलाव नहीं करता है और इसमें कोई अतिरिक्त सुविधा नहीं होती. VanillaJavaBuilder का इस्तेमाल, किसी भी इन-बिल्ट टूलचेन से नहीं किया जाता.
Bazel, कंपाइलेशन के दौरान JavaBuilder के अलावा, कई अन्य टूल का इस्तेमाल करता है.
ijar टूल, कॉल
सिग्नेचर के अलावा बाकी सब कुछ हटाने के लिए, jar फ़ाइलों को प्रोसेस करता है. इससे बनने वाली जार को हेडर जार कहा जाता है. इनका इस्तेमाल, कंपाइलेशन की इंक्रीमेंटैलिटी को बेहतर बनाने के लिए किया जाता है. इसके लिए, किसी फ़ंक्शन के बॉडी में बदलाव होने पर, सिर्फ़ डाउनस्ट्रीम डिपेंडेंट को फिर से कंपाइल किया जाता है.
singlejar टूल, कई jar फ़ाइलों को एक साथ पैक करके एक फ़ाइल बनाता है.
genclass टूल, Java कंपाइलेशन के आउटपुट को पोस्ट-प्रोसेस करता है. साथ ही, यह एक jar बनाता है, जिसमें सिर्फ़ उन सोर्स के लिए क्लास फ़ाइलें होती हैं जिन्हें एनोटेशन प्रोसेसर ने जनरेट किया था.
JacocoRunner टूल, इंस्ट्रूमेंट की गई फ़ाइलों पर Jacoco चलाता है और नतीजे LCOV फ़ॉर्मैट में दिखाता है.
TestRunner टूल, कंट्रोल किए गए एनवायरमेंट में JUnit 4 टेस्ट को एक्ज़ीक्यूट करता है.
default_java_toolchain मैक्रो को BUILD फ़ाइल में जोड़कर और इसे रजिस्टर करके, कंपाइलेशन को फिर से कॉन्फ़िगर किया जा सकता है. इसके लिए, register_toolchains नियम को MODULE.bazel फ़ाइल में जोड़ें या --extra_toolchains फ़्लैग का इस्तेमाल करें.
टूलचेन का इस्तेमाल सिर्फ़ तब किया जाता है, जब source_version एट्रिब्यूट, --java_language_version फ़्लैग से तय की गई वैल्यू से मैच करता है.
टूलचेन कॉन्फ़िगरेशन का उदाहरण:
load(
"@rules_java//toolchains: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 = "@rules_java//toolchains: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: सभी सुविधाएं, जेडीके के वर्शन >= 9 के साथ काम करता हैVANILLA_TOOLCHAIN_CONFIGURATION: कोई अतिरिक्त सुविधा नहीं, किसी भी वेंडर के जेडीके के साथ काम करता है.PREBUILT_TOOLCHAIN_CONFIGURATION: डिफ़ॉल्ट के जैसा, लेकिन सिर्फ़ प्रीबिल्ट टूल (ijar,singlejar) का इस्तेमाल करता हैNONPREBUILT_TOOLCHAIN_CONFIGURATION: डिफ़ॉल्ट के जैसा, लेकिन सभी टूल सोर्स से बनाए जाते हैं. यह अलग-अलग libc वाले ऑपरेटिंग सिस्टम पर काम आ सकता है
जेवीएम और Java कंपाइलर फ़्लैग को कॉन्फ़िगर करना
जेवीएम और javac फ़्लैग को, फ़्लैग या
default_java_toolchain एट्रिब्यूट की मदद से कॉन्फ़िगर किया जा सकता है.
काम के फ़्लैग, --jvmopt, --host_jvmopt, --javacopt, और
--host_javacopt हैं.
काम के default_java_toolchain एट्रिब्यूट, javacopts, jvm_opts,
javabuilder_jvm_opts, और turbine_jvm_opts हैं.
पैकेज के लिए खास Java कंपाइलर फ़्लैग कॉन्फ़िगरेशन
default_java_toolchain के package_configuration एट्रिब्यूट का इस्तेमाल करके, खास सोर्स फ़ाइलों के लिए अलग-अलग Java कंपाइलर फ़्लैग कॉन्फ़िगर किए जा सकते हैं.
कृपया नीचे दिया गया उदाहरण देखें.
load("@rules_java//toolchains: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 सोर्स कोड के कई वर्शन
Bazel, एक बिल्ड में Java सोर्स के सिर्फ़ एक वर्शन को कंपाइल कर सकता है. बिल्ड. इसका मतलब है कि Java टेस्ट या ऐप्लिकेशन बनाते समय, सभी डिपेंडेंसी को Java के एक ही वर्शन के हिसाब से बनाया जाता है.
हालांकि, अलग-अलग फ़्लैग का इस्तेमाल करके, अलग-अलग बिल्ड को एक्ज़ीक्यूट किया जा सकता है.
अलग-अलग फ़्लैग का इस्तेमाल करने के काम को आसान बनाने के लिए, किसी खास वर्शन के लिए फ़्लैग के सेट को .bazelrc कॉन्फ़िग के साथ ग्रुप किया जा सकता है:
build:java8 --java_language_version=8
build:java8 --java_runtime_version=local_jdk_8
build:java11 --java_language_version=11
build:java11 --java_runtime_version=remotejdk_11
इन कॉन्फ़िग का इस्तेमाल --config फ़्लैग के साथ किया जा सकता है. उदाहरण के लिए
bazel test --config=java11 //:java11_test.