mod कमांड, उपयोगकर्ता को उसकी बाहरी डिपेंडेंसी का ग्राफ़ समझने में मदद करने के लिए कई टूल उपलब्ध कराती है. इसकी मदद से, डिपेंडेंसी ग्राफ़ को विज़ुअलाइज़ किया जा सकता है. साथ ही, यह पता लगाया जा सकता है कि ग्राफ़ में कोई खास मॉड्यूल या मॉड्यूल का कोई वर्शन क्यों मौजूद है. इसके अलावा, मॉड्यूल को बैकअप करने वाली रिपो की परिभाषाएं देखी जा सकती हैं. साथ ही, मॉड्यूल एक्सटेंशन और उनसे जनरेट होने वाली रिपो के इस्तेमाल की जांच की जा सकती है. इसके अलावा, अन्य फ़ंक्शन भी इस्तेमाल किए जा सकते हैं.
सिंटैक्स
bazel mod <subcommand> [<options>] [<arg> [<arg>...]]
उपलब्ध सब-कमांड और उनके लिए ज़रूरी आर्ग्युमेंट यहां दिए गए हैं:
graph: यह प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाता है. यह ग्राफ़, रूट मॉड्यूल से शुरू होता है. अगर--fromमें एक या उससे ज़्यादा मॉड्यूल तय किए जाते हैं, तो ये मॉड्यूल सीधे रूट के नीचे दिखते हैं. साथ ही, ग्राफ़ सिर्फ़ इनसे शुरू होकर बढ़ता है. उदाहरण के लिए, यहां देखें (उदाहरण).deps <arg>...: यह तय किए गए हर मॉड्यूल की हल की गई डायरेक्ट डिपेंडेंसी दिखाता है. यहgraphकी तरह ही काम करता है.all_paths <arg>...: यह --from मॉड्यूल से टारगेट मॉड्यूल तक के सभी डिपेंडेंसी पाथ दिखाता है. आउटपुट को आसान बनाने के लिए, एक ही सफ़िक्स वाले कई पाथ होने पर, सिर्फ़ सबसे छोटा पहला पाथ दिखाया जाता है. उदाहरण के लिए, A -> B -> X दिखाया जाएगा. हालांकि, लंबा पाथ A -> C -> B -> X नहीं दिखाया जाएगा. दूसरे शब्दों में, हर उस मॉड्यूल Y के लिए जो सीधे तौर पर टारगेट मॉड्यूल X पर निर्भर करता है, आउटपुट में सिर्फ़ वह सबसे छोटा पाथ शामिल होता है जो Y से होकर X तक जाता है.path <arg>...: इसका सिमैंटिक,all_pathsजैसा ही होता है. हालांकि, यह--fromमॉड्यूल में से किसी एक से, आर्ग्युमेंट मॉड्यूल में से किसी एक तक का सिर्फ़ एक पाथ दिखाता है.explain <arg>...: यह डिपेंडेंसी ग्राफ़ में तय किए गए मॉड्यूल के दिखने की सभी जगहें दिखाता है. साथ ही, उन मॉड्यूल के बारे में भी बताता है जो सीधे तौर पर उन पर निर्भर करते हैं.explainकमांड का आउटपुट, असल मेंall_pathsकमांड का छोटा वर्शन होता है. इसमें ये चीज़ें शामिल होती हैं: 1) रूट मॉड्यूल; 2) रूट मॉड्यूल की डायरेक्ट डिपेंडेंसी जो आर्ग्युमेंट मॉड्यूल की ओर ले जाती हैं; 3) आर्ग्युमेंट मॉड्यूल के डायरेक्ट डिपेंडेंट; और 4) आर्ग्युमेंट मॉड्यूल (उदाहरण के लिए, यहां देखें).show_repo <arg>...: यह तय की गई रिपो की परिभाषाएं दिखाता है. उदाहरण के लिए, यहां देखें (उदाहरण). पूरे डिपेंडेंसी ग्राफ़ में मौजूद सभी रिपो की परिभाषाएं दिखाने के लिए,--all_reposका इस्तेमाल करें. वहीं,--base_moduleसे दिखने वाली सभी रिपो की परिभाषाएं दिखाने के लिए,--all_visible_reposका इस्तेमाल करें.show_extension <extension>...: यह तय किए गए हर एक्सटेंशन के बारे में जानकारी दिखाता है. जैसे, जनरेट की गई रिपो की सूची के साथ-साथ, वे मॉड्यूल जोuse_repoका इस्तेमाल करके उन्हें इंपोर्ट करते हैं. इसके अलावा, हर उस मॉड्यूल में उस एक्सटेंशन के इस्तेमाल की सूची भी दिखाता है जिसमें उसका इस्तेमाल किया गया है. इस सूची में, तय किए गए टैग औरuse_repoकॉल शामिल होते हैं. उदाहरण के लिए, यहां देखें (उदाहरण).
<arg> का मतलब एक या उससे ज़्यादा मॉड्यूल या रिपो से है. यह इनमें से कोई एक हो सकता है:
लिटरल स्ट्रिंग
<root>: यह रूट मॉड्यूल है, जो आपके मौजूदा प्रोजेक्ट को दिखाता है.<name>@<version>: यह वर्शन<version>पर मौजूद मॉड्यूल<name>है. रजिस्ट्री से बाहर के किसी मॉड्यूल के लिए,<version>के तौर पर अंडरस्कोर (_) का इस्तेमाल करें.<name>: यह मॉड्यूल<name>के सभी मौजूदा वर्शन हैं.@<repo_name>: यह--base_moduleके कॉन्टेक्स्ट में, दिए गए नाम वाली रिपो है.@@<repo_name>: यह दिए गए कैननिकल नाम वाली रिपो है.
ऐसे कॉन्टेक्स्ट में जहां मॉड्यूल तय करना ज़रूरी है, वहां उन रिपो के लिए <arg> का इस्तेमाल किया जा सकता है जो मॉड्यूल से जुड़ी हैं. हालांकि, एक्सटेंशन से जनरेट होने वाली रिपो के लिए इसका इस्तेमाल नहीं किया जा सकता. इसके उलट, ऐसे कॉन्टेक्स्ट में जहां रिपो तय करना ज़रूरी है, वहां मॉड्यूल के लिए <arg>s का इस्तेमाल किया जा सकता है.
<extension> का फ़ॉर्मैट <arg><label_to_bzl_file>%<extension_name> होना चाहिए.
<label_to_bzl_file> वाला हिस्सा, रिपो से जुड़ा लेबल होना चाहिए. उदाहरण के लिए,
//pkg/path:file.bzl.
ग्राफ़ कमांड के विकल्प
ये विकल्प सिर्फ़ उन सब-कमांड पर असर डालते हैं जो ग्राफ़ प्रिंट करती हैं. जैसे, (graph,
deps, all_paths, path, और explain):
--from <arg>[,<arg>[,...]]डिफ़ॉल्ट:<root>: ये वे मॉड्यूल हैं जिनसेgraph,all_paths,path, औरexplainमें ग्राफ़ बढ़ता है. ज़्यादा जानकारी के लिए, सब-कमांड के ब्यौरे देखें.--verboseडिफ़ॉल्ट: "false": आउटपुट ग्राफ़ में, हर मॉड्यूल के वर्शन रिज़ॉल्यूशन के बारे में ज़्यादा जानकारी शामिल करें. अगर रिज़ॉल्यूशन के दौरान मॉड्यूल का वर्शन बदला गया है, तो यह दिखाएं कि कौनसे वर्शन ने उसे बदला है या उसका ओरिजनल वर्शन क्या था. साथ ही, यह भी दिखाएं कि उसे क्यों बदला गया और अगर इसकी वजह, मिनिमल वर्शन सिलेक्शनथी, तो किन मॉड्यूल ने नया वर्शन मांगा.--include_unusedडिफ़ॉल्ट: "false": आउटपुट ग्राफ़ में उन मॉड्यूल को शामिल करें जो पहले डिपेंडेंसी ग्राफ़ में मौजूद थे, लेकिन मॉड्यूल रिज़ॉल्यूशन के बाद इस्तेमाल में नहीं रहे.--extension_info <mode>: आउटपुट ग्राफ़ में, मॉड्यूल एक्सटेंशन के इस्तेमाल के बारे में जानकारी शामिल करें (उदाहरण के लिए, यहां देखें).<mode>इनमें से कोई एक हो सकता है:hidden(डिफ़ॉल्ट): एक्सटेंशन के बारे में कुछ न दिखाएं.usages: हर उस मॉड्यूल के तहत एक्सटेंशन दिखाएं जहां उनका इस्तेमाल किया गया है. इन्हें$<extension>के फ़ॉर्मैट में प्रिंट किया जाता है.repos:usagesके अलावा, हर एक्सटेंशन के इस्तेमाल के तहत,use_repoका इस्तेमाल करके इंपोर्ट की गई रिपो दिखाएं.all:usagesऔरreposके अलावा, एक्सटेंशन से जनरेट होने वाली उन रिपो को भी दिखाएं जिन्हें किसी मॉड्यूल ने इंपोर्ट नहीं किया है. ये अतिरिक्त रिपो, आउटपुट में अपने जनरेटिंग एक्सटेंशन के पहले दिखने पर दिखाई जाती हैं. साथ ही, इन्हें डॉटेड एज से कनेक्ट किया जाता है.
--extension_filter <extension>[,<extension>[,...]]: अगर यह तय किया जाता है, तो आउटपुट ग्राफ़ में सिर्फ़ वे मॉड्यूल शामिल होते हैं जो तय किए गए एक्सटेंशन का इस्तेमाल करते हैं. साथ ही, उन मॉड्यूल तक ले जाने वाले पाथ भी शामिल होते हैं. एक्सटेंशन की खाली सूची तय करना (जैसे,--extension_filter=), डिपेंडेंसी ग्राफ़ में किसी भी मॉड्यूल के इस्तेमाल किए गए सभी एक्सटेंशन तय करने के बराबर है.--depth <N>: यह आउटपुट ग्राफ़ की डेप्थ है. डेप्थ 1 होने पर, सिर्फ़ रूट और उसकी डायरेक्ट डिपेंडेंसी दिखती हैं.explainके लिए डिफ़ॉल्ट डेप्थ 1,depsके लिए 2, और बाकी के लिए इनफ़िनिटी होती है.--cyclesडिफ़ॉल्ट: "false": आउटपुट ग्राफ़ में साइकल एज शामिल करें.--include_builtinडिफ़ॉल्ट: "false": आउटपुट ग्राफ़ में, बिल्ट-इन मॉड्यूल (जैसे,@bazel_tools) शामिल करें. यह फ़्लैग डिफ़ॉल्ट रूप से बंद होता है, क्योंकि बिल्ट-इन मॉड्यूल पर हर दूसरा मॉड्यूल, सीधे तौर पर निर्भर करता है. इससे आउटपुट में काफ़ी गड़बड़ी हो जाती है.--charset <charset>डिफ़ॉल्ट: utf8: टेक्स्ट आउटपुट के लिए इस्तेमाल किया जाने वाला कैरेक्टर सेट तय करें. मान्य वैल्यू"utf8"और"ascii"हैं. इनमें सिर्फ़ एक अहम अंतर है. वह यह है कि"text"आउटपुट फ़ॉर्मैट में ग्राफ़ बनाने के लिए इस्तेमाल किए जाने वाले खास कैरेक्टर,"ascii"कैरेक्टर सेट में मौजूद नहीं होते. इसलिए,"ascii"कैरेक्टर सेट, पुराने प्लैटफ़ॉर्म पर भी इस्तेमाल किया जा सकता है. इन प्लैटफ़ॉर्म पर, यूनिकोड का इस्तेमाल नहीं किया जा सकता.--output <mode>: आउटपुट ग्राफ़ में, मॉड्यूल एक्सटेंशन के इस्तेमाल के बारे में जानकारी शामिल करें.<mode>इनमें से कोई एक हो सकता है:text(डिफ़ॉल्ट): यह आउटपुट ग्राफ़ का ऐसा वर्शन है जिसे आसानी से पढ़ा जा सकता है. इसे ट्री के तौर पर फ़्लैट किया जाता है.json: यह ग्राफ़ को JSON ऑब्जेक्ट के तौर पर आउटपुट करता है. इसे ट्री के तौर पर फ़्लैट किया जाता है.graph: यह ग्राफ़ को Graphviz dot वर्शन में आउटपुट करता है.
bazel mod graph --output graph | dot -Tsvg > /tmp/graph.svg
show_repo के विकल्प
show_repo, आउटपुट के अलग-अलग फ़ॉर्मैट के साथ काम करता है:
--output <mode>: इससे, रिपॉज़िटरी की परिभाषाएं दिखाने का तरीका बदलता है.<mode>इनमें से कोई एक हो सकता है:text(डिफ़ॉल्ट): यह रिपॉज़िटरी की परिभाषाएं Starlark में दिखाता है.streamed_proto: यह लेंथ-डेलिमिटेडRepositoryप्रोटोकॉल बफ़र की स्ट्रीम प्रिंट करता है.streamed_jsonproto: यह--output streamed_protoकी तरह ही काम करता है. हालांकि, यहRepositoryप्रोटोकॉल बफ़र की स्ट्रीम को NDJSON फ़ॉर्मैट में प्रिंट करता है.
दूसरे विकल्प
दूसरे विकल्पों में ये शामिल हैं:
--base_module <arg>डिफ़ॉल्ट:<root>: यह एक ऐसा मॉड्यूल तय करता है जिसके हिसाब से, आर्ग्युमेंट में रिपो के नाम की व्याख्या की जाती है. ध्यान दें कि यह आर्ग्युमेंट,@<repo_name>के फ़ॉर्मैट में भी हो सकता है. इसकी व्याख्या हमेशा रूट मॉड्यूल के हिसाब से की जाती है.--extension_usages <arg>[,<arg>[,...]]: यहshow_extensionको फ़िल्टर करके, सिर्फ़ तय किए गए मॉड्यूल से एक्सटेंशन के इस्तेमाल को दिखाता है.
उदाहरण
यहां, Bazel के किसी असली प्रोजेक्ट पर mod कमांड के कुछ संभावित इस्तेमाल दिखाए गए हैं. इससे आपको यह सामान्य जानकारी मिलेगी कि अपने प्रोजेक्ट की बाहरी डिपेंडेंसी की जांच करने के लिए, इसका इस्तेमाल कैसे किया जा सकता है.
MODULE.bazel फ़ाइल:
module(
name = "my_project",
version = "1.0",
)
bazel_dep(name = "bazel_skylib", version = "1.1.1", repo_name = "skylib1")
bazel_dep(name = "bazel_skylib", version = "1.2.0", repo_name = "skylib2")
multiple_version_override(module_name = "bazel_skylib", versions = ["1.1.1", "1.2.0"])
bazel_dep(name = "stardoc", version = "0.5.0")
bazel_dep(name = "rules_java", version = "5.0.0")
toolchains = use_extension("@rules_java//java:extensions.bzl", "toolchains")
use_repo(toolchains, my_jdk="remotejdk17_linux")
|
|
अपने प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाएं.
bazel mod graph<root> (my_project@1.0) ├───bazel_skylib@1.1.1 │ └───platforms@0.0.4 ├───bazel_skylib@1.2.0 │ └───platforms@0.0.4 ... ├───rules_java@5.0.0 │ ├───platforms@0.0.4 ... │ ├───rules_cc@0.0.1 │ │ ├───bazel_skylib@1.1.1 ... │ │ └───platforms@0.0.4 ... │ └───rules_proto@4.0.0 │ ├───bazel_skylib@1.1.1 ... │ └───rules_cc@0.0.1 ... └───stardoc@0.5.0 ├───bazel_skylib@1.1.1 ... └───rules_java@5.0.0 ...पूरा डिपेंडेंसी ग्राफ़ दिखाएं. इसमें, इस्तेमाल में नहीं रहे मॉड्यूल और वर्शन रिज़ॉल्यूशन के बारे में ज़्यादा जानकारी शामिल करें.
bazel mod graph --include_unused --verbose<root> (my_project@1.0) ├───bazel_skylib@1.1.1 │ └───platforms@0.0.4 ├───bazel_skylib@1.2.0 │ └───platforms@0.0.4 ... ├───rules_java@5.0.0 │ ├───platforms@0.0.4 ... │ ├───rules_cc@0.0.1 │ │ ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override) │ │ ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) │ │ └───platforms@0.0.4 ... │ └───rules_proto@4.0.0 │ ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override) │ ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) │ └───rules_cc@0.0.1 ... └───stardoc@0.5.0 ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) ├───rules_java@5.0.0 ... (was 4.0.0, cause <root>, bazel_tools@_) ├───bazel_skylib@1.0.3 (to 1.1.1, cause multiple_version_override) │ └───platforms@0.0.4 ... └───rules_java@4.0.0 (to 5.0.0, cause <root>, bazel_tools@_) ├───bazel_skylib@1.0.3 ... (to 1.1.1, cause multiple_version_override) └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override)कुछ खास मॉड्यूल से बढ़ा हुआ डिपेंडेंसी ग्राफ़ दिखाएं.
bazel mod graph --from rules_java --include_unused<root> (my_project@1.0) ├───rules_java@5.0.0 │ ├───platforms@0.0.4 │ ├───rules_cc@0.0.1 │ │ ├───bazel_skylib@1.0.3 ... (unused) │ │ ├───bazel_skylib@1.1.1 ... │ │ └───platforms@0.0.4 ... │ └───rules_proto@4.0.0 │ ├───bazel_skylib@1.0.3 ... (unused) │ ├───bazel_skylib@1.1.1 ... │ └───rules_cc@0.0.1 ... └╌╌rules_java@4.0.0 (unused) ├───bazel_skylib@1.0.3 (unused) │ └───platforms@0.0.4 ... └───bazel_skylib@1.1.1 └───platforms@0.0.4 ...अपने दो मॉड्यूल के बीच के सभी पाथ दिखाएं.
bazel mod all_paths bazel_skylib@1.1.1 --from rules_proto<root> (my_project@1.0) └╌╌rules_proto@4.0.0 ├───bazel_skylib@1.1.1 └───rules_cc@0.0.1 └───bazel_skylib@1.1.1 ...देखें कि आपका प्रोजेक्ट, कुछ मॉड्यूल पर क्यों और कैसे निर्भर करता है.
bazel mod explain @skylib1 --verbose --include_unused<root> (my_project@1.0) ├───bazel_skylib@1.1.1 ├───rules_java@5.0.0 │ ├───rules_cc@0.0.1 │ │ └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) │ └───rules_proto@4.0.0 │ ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) │ └───rules_cc@0.0.1 ... └───stardoc@0.5.0 ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) ├╌╌rules_cc@0.0.1 │ └───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) └╌╌rules_proto@4.0.0 ├───bazel_skylib@1.1.1 ... (was 1.0.3, cause multiple_version_override) └───rules_cc@0.0.1 ...अपने मॉड्यूल की रिपो का बुनियादी नियम देखें.
bazel mod show_repo rules_cc stardoc## rules_cc@0.0.1: load("@@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "rules_cc+", urls = ["https://bcr.bazel.build/test-mirror/github.com/bazelbuild/rules_cc/releases/download/0.0.1/rules_cc-0.0.1.tar.gz", "https://github.com/bazelbuild/rules_cc/releases/download/0.0.1/rules_cc-0.0.1.tar.gz"], integrity = "sha256-Tcy/0iwN7xZMj0dFi9UODHFI89kgAs20WcKpamhJgkE=", strip_prefix = "", remote_patches = {"https://bcr.bazel.build/modules/rules_cc/0.0.1/patches/add_module_extension.patch": "sha256-g3+zmGs0YT2HKOVevZpN0Jet89Ylw90Cp9XsIAY8QqU="}, remote_patch_strip = 1, ) ## stardoc: load("@@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "stardoc+", urls = ["https://bcr.bazel.build/test-mirror/github.com/bazelbuild/stardoc/releases/download/0.5.0/stardoc-0.5.0.tar.gz", "https://github.com/bazelbuild/stardoc/releases/download/0.5.0/stardoc-0.5.0.tar.gz"], integrity = "sha256-yXlNzIAmow/2fPfPkeviRcopSyCwcYRdEsGSr+JDrXI=", strip_prefix = "", remote_patches = {}, remote_patch_strip = 0, )bazel mod show_repoका इस्तेमाल,use_repoसे इंपोर्ट की गई रिपो और रिपोuse_repo_ruleसे बनाई गई रिपो के साथ भी किया जा सकता है. अगरshow_repoको रिपॉज़िटरी के नाम या--all_visible_reposके साथ शुरू किया जाता है, तो रिपॉज़िटरी का नाम,##से शुरू होने वाली लाइन पर दिखता है.bazel mod show_repo @jq_linux_arm64 bazel mod show_repo --all_visible_repos## @jq_linux_arm64: load("@@bazel_tools//tools/build_defs/repo:http.bzl", "http_file") http_file( name = "+http_file+jq_linux_arm64", executable = True, integrity = "sha256-TdLYoGYd8LIvG7mh+YMPBrbzuPfZEhGh7118TwaotKU=", urls = ["https://github.com/jqlang/jq/releases/download/jq-1.7.1/jq-linux-arm64"], )देखें कि आपके डिपेंडेंसी ग्राफ़ में, किन मॉड्यूल एक्सटेंशन का इस्तेमाल किया गया है.
bazel mod graph --extension_info=usages<root> (my_project@1.0) ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains ├───rules_java@5.0.0 # │ ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains │ ├───rules_cc@0.0.1 # │ │ └───$@@rules_cc.0.0.1//bzlmod:extensions.bzl%cc_configure │ └───rules_proto@4.0.0 │ └───rules_cc@0.0.1 ... └───stardoc@0.5.0 └───rules_java@5.0.0 ...डिपेंडेंसी ग्राफ़ के हिस्से के तौर पर, देखें कि किसी खास एक्सटेंशन से कौनसी रिपॉज़िटरी जनरेट और इंपोर्ट की गई हैं.
bazel mod show_extension @@rules_java+5.0.0//java:extensions.bzl%toolchains<root> (my_project@1.0) ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains │ ├───remotejdk17_linux │ ├╌╌remotejdk11_linux │ ├╌╌remotejdk11_linux_aarch64 │ ├╌╌remotejdk11_linux_ppc64le │ ├╌╌remotejdk11_linux_s390x ...(some lines omitted)... ├───rules_java@5.0.0 # │ └───$@@rules_java.5.0.0//java:extensions.bzl%toolchains ... │ ├───local_jdk │ ├───remote_java_tools │ ├───remote_java_tools_darwin │ ├───remote_java_tools_linux │ ├───remote_java_tools_windows │ ├───remotejdk11_linux_aarch64_toolchain_config_repo │ ├───remotejdk11_linux_ppc64le_toolchain_config_repo ...(some lines omitted)... └───stardoc@0.5.0 └───rules_java@5.0.0 ...किसी एक्सटेंशन से जनरेट की गई रिपॉज़िटरी की सूची देखें. साथ ही, यह भी देखें कि हर मॉड्यूल में उस एक्सटेंशन का इस्तेमाल कैसे किया जाता है.
bazel mod graph --extension_info=all --extension_filter=@rules_java//java:extensions.bzl%toolchains## @@rules_java.5.0.0//java:extensions.bzl%toolchains: Fetched repositories: - local_jdk (imported by bazel_tools@_, rules_java@5.0.0) - remote_java_tools (imported by bazel_tools@_, rules_java@5.0.0) - remote_java_tools_darwin (imported by bazel_tools@_, rules_java@5.0.0) - remote_java_tools_linux (imported by bazel_tools@_, rules_java@5.0.0) - remote_java_tools_windows (imported by bazel_tools@_, rules_java@5.0.0) - remotejdk11_linux_aarch64_toolchain_config_repo (imported by rules_java@5.0.0) - remotejdk11_linux_ppc64le_toolchain_config_repo (imported by rules_java@5.0.0) ...(some lines omitted)... - remotejdk17_linux (imported by <root>) - remotejdk11_linux - remotejdk11_linux_aarch64 - remotejdk11_linux_ppc64le - remotejdk11_linux_s390x - remotejdk11_macos ...(some lines omitted)... # Usage in <root> at <root>/MODULE.bazel:14:27 with the specified attributes: use_repo( toolchains, my_jdk="remotejdk17_linux", ) # Usage in bazel_tools@_ at bazel_tools@_/MODULE.bazel:23:32 with the specified attributes: use_repo( toolchains, "local_jdk", "remote_java_tools", "remote_java_tools_linux", "remote_java_tools_windows", "remote_java_tools_darwin", ) # Usage in rules_java@5.0.0 at rules_java@5.0.0/MODULE.bazel:30:27 with the specified attributes: use_repo( toolchains, "remote_java_tools", "remote_java_tools_linux", "remote_java_tools_windows", "remote_java_tools_darwin", "local_jdk", "remotejdk11_linux_toolchain_config_repo", "remotejdk11_macos_toolchain_config_repo", "remotejdk11_macos_aarch64_toolchain_config_repo", ...(some lines omitted)... )एक्सटेंशन से जनरेट की गई कुछ रिपॉज़िटरी का बुनियादी नियम देखें.
bazel mod show_repo --base_module=rules_java @remote_java_tools## @remote_java_tools: # <builtin> http_archive( name = "rules_java++toolchains+remote_java_tools", urls = ["https://mirror.bazel.build/bazel_java_tools/releases/java/v11.5/java_tools-v11.5.zip", "https://github.com/bazelbuild/java_tools/releases/download/java_v11.5/java_tools-v11.5.zip"], sha256 = "b763ee80e5754e593fd6d5be6d7343f905bc8b73d661d36d842b024ca11b6793", ) # Rule http_archive defined at (most recent call last): # /home/user/.cache/bazel/_bazel_user/6e893e0f5a92cc4cf5909a6e4b2770f9/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31 in <toplevel>