mod कमांड

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Basel 6.3.0 में पेश किया गया mod निर्देश, Bzlmod के चालू होने पर, उपयोगकर्ताओं को बाहरी डिपेंडेंसी ग्राफ़ को समझने में मदद करने के लिए कई टूल देता है. इसकी मदद से, डिपेंडेंसी ग्राफ़ को विज़ुअलाइज़ किया जा सकता है. साथ ही, यह भी पता लगाया जा सकता है कि ग्राफ़ में कोई मॉड्यूल या मॉड्यूल का कोई वर्शन क्यों मौजूद है. इसके अलावा, मॉड्यूल के बैकअप के तौर पर मौजूद रिपॉज़िटरी की परिभाषाएं देखी जा सकती हैं. साथ ही, मॉड्यूल एक्सटेंशन के इस्तेमाल और जनरेट किए गए रिपॉज़िटरी की जांच की जा सकती है.

सिंटैक्स

bazel mod <subcommand> [<options>] [<arg> [<arg>...]]

उपलब्ध सब-कमांड और उनके ज़रूरी आर्ग्युमेंट ये हैं:

  • graph: यह रूट मॉड्यूल से शुरू होकर, प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाता है. अगर --from में एक या एक से ज़्यादा मॉड्यूल तय किए गए हैं, तो ये मॉड्यूल सीधे रूट के नीचे दिखाए जाते हैं. साथ ही, ग्राफ़ को सिर्फ़ इनसे शुरू करके बड़ा किया जाता है (उदाहरण देखें).

  • deps <arg>...: यह graph की तरह ही, हर खास मॉड्यूल की रिज़ॉल्व की गई डायरेक्ट डिपेंडेंसी दिखाता है.

  • all_paths <arg>...: रूट से लेकर तय किए गए <arg>... तक के सभी मौजूदा पाथ दिखाता है. अगर --from में एक या एक से ज़्यादा मॉड्यूल तय किए गए हैं, तो ये मॉड्यूल सीधे रूट में दिखते हैं. साथ ही, ग्राफ़ में --from मॉड्यूल से लेकर आर्ग्युमेंट मॉड्यूल तक का कोई भी मौजूदा पाथ होता है (उदाहरण देखें).

  • path <arg>...: इसका सेमेंटेटिक्स all_paths जैसा ही होता है. हालांकि, यह --from मॉड्यूल में से किसी एक से, आर्ग्युमेंट मॉड्यूल में से किसी एक तक सिर्फ़ एक पाथ दिखाता है.

  • explain <arg>...: यह उन सभी जगहों को दिखाता है जहां डिपेंडेंसी ग्राफ़ में बताए गए मॉड्यूल दिखते हैं. साथ ही, उन मॉड्यूल को भी दिखाता है जो सीधे तौर पर उन पर निर्भर होते हैं. explain कमांड का आउटपुट, असल में all_paths कमांड का छोटा वर्शन होता है. इसमें ये चीज़ें शामिल होती हैं: 1) रूट मॉड्यूल; 2) रूट मॉड्यूल की डायरेक्ट डिपेंडेंसी, जो आर्ग्युमेंट मॉड्यूल पर ले जाती हैं; 3) आर्ग्युमेंट मॉड्यूल की डायरेक्ट डिपेंडेंसी; और 4) आर्ग्युमेंट मॉड्यूल (उदाहरण देखें).

  • show_repo <arg>...: यह बताता है कि किसी खास रिपॉज़िटरी में क्या है. उदाहरण देखें.

  • show_extension <extension>...: हर एक एक्सटेंशन के बारे में जानकारी दिखाता है: जनरेट किए गए रेपो की सूची और ऐसे मॉड्यूल की सूची जो use_repo का इस्तेमाल करके इंपोर्ट करते हैं. साथ ही, हर उस मॉड्यूल में इस एक्सटेंशन के इस्तेमाल की सूची जहां इसका इस्तेमाल होता है. इसमें तय टैग और use_repo कॉल शामिल हैं (उदाहरण देखें).

<arg> से एक या उससे ज़्यादा मॉड्यूल या रिपॉज़िटरी का पता चलता है. यह इनमें से कोई एक हो सकता है:

  • लिटरल स्ट्रिंग <root>: यह आपके मौजूदा प्रोजेक्ट को दिखाने वाला रूट मॉड्यूल है.

  • <name>@<version>: <version> वर्शन पर मॉड्यूल <name>. ऐसे मॉड्यूल के लिए जिसमें रजिस्ट्री बदलाव नहीं किया गया है, <version> के तौर पर अंडरस्कोर (_) का इस्तेमाल करें.

  • <name>: <name> मॉड्यूल के सभी मौजूदा वर्शन.

  • @<repo_name>: --base_module के संदर्भ में, साफ़ तौर पर दिखने वाला नाम वाला रिपॉज़िटरी.

  • @@<repo_name>: वह रिपॉज़िटरी जिसका कैननिकल नाम दिया गया है.

अगर किसी कॉन्टेक्स्ट में मॉड्यूल की जानकारी देनी है, तो मॉड्यूल से जुड़े रीपो के रेफ़रंस के तौर पर <arg> का इस्तेमाल भी किया जा सकता है. यह रेफ़रंस, एक्सटेंशन से जनरेट किए गए रीपो के रेफ़रंस के बजाय होता है. इसके उलट, किसी ऐसे कॉन्टेक्स्ट में जहां खास रिपॉज़िटरी की ज़रूरत होती है, मॉड्यूल के बारे में बताने वाले <arg>, उनसे जुड़े रिपॉज़िटरी के लिए इस्तेमाल किए जा सकते हैं.

<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 डिफ़ॉल्ट: "गलत": आउटपुट ग्राफ़ में हर मॉड्यूल के वर्शन रिज़ॉल्यूशन के बारे में ज़्यादा जानकारी शामिल करें. अगर रिज़ॉल्यूशन के दौरान मॉड्यूल का वर्शन बदला है, तो दिखाएं कि इसे किस वर्शन से बदला गया है या मूल वर्शन क्या था, इसकी वजह क्या थी, और अगर वजह कम से कम वर्शन चुनना था, तो कौनसे मॉड्यूल ने नए वर्शन के लिए अनुरोध किया.

  • --include_unused डिफ़ॉल्ट: "गलत": आउटपुट ग्राफ़ में वे मॉड्यूल शामिल करें जो मूल रूप से डिपेंडेंसी ग्राफ़ में मौजूद थे, लेकिन मॉड्यूल रिज़ॉल्यूशन के बाद उनका इस्तेमाल नहीं किया गया.

  • --extension_info <mode>: आउटपुट ग्राफ़ में, मॉड्यूल एक्सटेंशन के इस्तेमाल के बारे में जानकारी शामिल करें (उदाहरण देखें). <mode> इनमें से कोई एक हो सकता है:

    • hidden (डिफ़ॉल्ट): एक्सटेंशन के बारे में कुछ भी न दिखाएं.

    • usages: एक्सटेंशन को हर उस मॉड्यूल में दिखाएं जहां उनका इस्तेमाल किया जाता है. इन्हें $<extension> के तौर पर प्रिंट किया जाता है.

    • repos: usages के अलावा, हर एक्सटेंशन के इस्तेमाल के नीचे, use_repo का इस्तेमाल करके इंपोर्ट किए गए रेपो को दिखाएं.

    • all: usages और repos के अलावा, एक्सटेंशन से जनरेट किए गए ऐसे रेपो भी दिखाएं जिन्हें किसी मॉड्यूल से इंपोर्ट नहीं किया जाता है. ये अतिरिक्त रिपॉज़िटरी, आउटपुट में उनके जनरेटिंग एक्सटेंशन की पहली बार होने पर दिखती हैं. साथ ही, इन्हें बिंदु वाले किनारे से जोड़ा जाता है.

  • --extension_filter <extension>[,<extension>[,...]]: अगर यह एट्रिब्यूट तय किया गया है, तो आउटपुट ग्राफ़ में सिर्फ़ वे मॉड्यूल शामिल होंगे जो तय किए गए एक्सटेंशन का इस्तेमाल करते हैं. साथ ही, उन मॉड्यूल पर ले जाने वाले पाथ भी शामिल होंगे. --extension_filter= में बताई गई तरह से, एक्सटेंशन की खाली सूची देना, डिपेंडेंसी ग्राफ़ में किसी भी मॉड्यूल के इस्तेमाल किए गए सभी एक्सटेंशन की जानकारी देने के बराबर है.

  • --depth <N>: आउटपुट ग्राफ़ की डेप्थ. एक डीपथ में सिर्फ़ रूट और उसकी डायरेक्ट डिपेंडेंसी दिखती हैं. डिफ़ॉल्ट रूप से, explain के लिए 1, deps के लिए 2 और अन्य के लिए अनंत होता है.

  • --cycles डिफ़ॉल्ट: "गलत": आउटपुट ग्राफ़ में साइकल के किनारों को शामिल करें.

  • --include_builtin डिफ़ॉल्ट: "गलत": आउटपुट ग्राफ़ में, पहले से मौजूद मॉड्यूल (जैसे कि @bazel_tools) शामिल करें. यह फ़्लैग डिफ़ॉल्ट रूप से बंद होता है, क्योंकि पहले से मौजूद मॉड्यूल, हर दूसरे मॉड्यूल पर निर्भर होते हैं. इससे आउटपुट बहुत ही गड़बड़ा हो जाता है.

  • --charset <charset> डिफ़ॉल्ट: utf8: टेक्स्ट आउटपुट के लिए इस्तेमाल किए जाने वाले charset की जानकारी दें. मान्य वैल्यू "utf8" और "ascii" हैं. "text" आउटपुट फ़ॉर्मैट में ग्राफ़ को ड्रॉ करने के लिए इस्तेमाल किए गए खास वर्णों में ही काफ़ी फ़र्क़ है. ये वर्ण "ascii" चेरसेट में मौजूद नहीं हैं. इसलिए, "ascii" charset मौजूद है, ताकि उन लेगसी प्लैटफ़ॉर्म पर भी इसका इस्तेमाल किया जा सके जो यूनिकोड का इस्तेमाल नहीं कर सकते.

  • --output <mode>: आउटपुट ग्राफ़ के हिस्से के तौर पर, मॉड्यूल एक्सटेंशन के इस्तेमाल के बारे में जानकारी शामिल करें. <mode> इनमें से कोई एक हो सकता है:

    • text (डिफ़ॉल्ट): आउटपुट ग्राफ़ का ऐसा वर्शन जिसे कोई भी व्यक्ति पढ़ सकता है (ट्री के तौर पर फ़्लैट किया गया).

    • json: ग्राफ़ को JSON ऑब्जेक्ट के तौर पर आउटपुट करता है (ट्री के तौर पर फ़्लैट किया गया).

    • graph: ग्राफ़ को Graphviz dot फ़ॉर्मैट में दिखाता है.

    bazel mod graph --output graph | dot -Tsvg > /tmp/graph.svg
    

दूसरे विकल्पों में ये शामिल हैं:

  • --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")
समस्या हल होने से पहले का ग्राफ़
समस्या हल होने से पहले का ग्राफ़
समस्या हल होने के बाद का ग्राफ़
समस्या हल होने के बाद का ग्राफ़
  1. अपने प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाएं.

    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 ...
    
  2. पूरा डिपेंडेंसी ग्राफ़ दिखाएं. इसमें, इस्तेमाल न किए गए मॉड्यूल और वर्शन रिज़ॉल्यूशन के बारे में ज़्यादा जानकारी शामिल होती है.

    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)
    
  3. कुछ खास मॉड्यूल से बड़ा किया गया डिपेंडेंसी ग्राफ़ दिखाएं.

    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 ...
    
  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 ...
    
  5. देखें कि आपका प्रोजेक्ट, कुछ मॉड्यूल पर क्यों और कैसे निर्भर करता है.

    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 ...
    
  6. अपने कुछ मॉड्यूल के रिपोज़ का बुनियादी नियम देखें.

    bazel mod show_repo rules_cc stardoc
    
    ## rules_cc@0.0.1:
    # <builtin>
    http_archive(
      name = "rules_cc~0.0.1",
      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,
    )
    # 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>
    
    ## stardoc:
    # <builtin>
    http_archive(
      name = "stardoc~0.5.0",
      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,
    )
    # 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>
    
  7. देखें कि आपके डिपेंडेंसी ग्राफ़ में कौनसे मॉड्यूल एक्सटेंशन इस्तेमाल किए जाते हैं.

    bazel mod graph --extension_info=usages --extension_filter=all
    
    <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 ...
    
  8. देखें कि डिपेंडेंसी ग्राफ़ के हिस्से के तौर पर, किसी खास एक्सटेंशन से कौनसी रिपॉज़िटरी जनरेट और इंपोर्ट की गई हैं.

    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 ...
    
  9. किसी एक्सटेंशन के जनरेट किए गए डेटा स्टोर की सूची देखें. साथ ही, यह भी देखें कि हर मॉड्यूल में उस एक्सटेंशन का इस्तेमाल कैसे किया जाता है.

    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)...
    )
    
  10. एक्सटेंशन से जनरेट हुई कुछ रिपॉज़िटरी के लिए लागू नियम देखें.

    bazel mod show_repo --base_module=rules_java @remote_java_tools
    
    ## @remote_java_tools:
    # <builtin>
    http_archive(
      name = "rules_java~5.0.0~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>