mod कमांड

एक रात का किराया · 8.5 · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

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

सिंटैक्स

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

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

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

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

  • all_paths <arg>...: यह --from मॉड्यूल से टारगेट मॉड्यूल तक के सभी डिपेंडेंसी पाथ दिखाता है. आउटपुट को आसान बनाने के लिए, जब एक से ज़्यादा पाथ का एक ही सफ़िक्स होता है, तो सिर्फ़ सबसे छोटा पाथ दिखाया जाता है. उदाहरण के लिए, A -> B -> X दिखाया जाएगा, लेकिन A -> C -> B -> X को नहीं दिखाया जाएगा. दूसरे शब्दों में कहें, तो टारगेट मॉड्यूल X पर सीधे तौर पर निर्भर रहने वाले हर मॉड्यूल Y के लिए, आउटपुट में सिर्फ़ Y से X तक पहुंचने वाला सबसे छोटा पाथ शामिल होता है.

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

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

  • show_repo <arg>...: यह बताए गए रिपॉज़िटरी की परिभाषा दिखाता है. उदाहरण देखें. --all_repos का इस्तेमाल करके, पूरे डिपेंडेंसी ग्राफ़ में मौजूद सभी रिपॉज़िटरी की परिभाषाएं दिखाएं. इसके अलावा, --all_visible_repos का इस्तेमाल करके, --base_module में दिखने वाली सभी रिपॉज़िटरी की परिभाषाएं दिखाएं.

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

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

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

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

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

  • @<repo_name>: --base_module के हिसाब से, दिए गए नाम वाला रेपो.

  • @@<repo_name>: दिए गए कैननिकल नाम वाली रिपो.

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

  • --include_unused default: "false": Include in the output graph the modules which were originally present in the dependency graph, but became unused after module resolution.

  • --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 default: "false": आउटपुट ग्राफ़ में साइकल के किनारों को शामिल करें.

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

  • --charset <charset> default: 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 की तरह ही होता है. यह NDJSON फ़ॉर्मैट में Repository प्रोटोकॉल बफ़र की स्ट्रीम प्रिंट करता है.

दूसरे विकल्प

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

  • --base_module <arg> default: <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")
समस्या ठीक होने से पहले का ग्राफ़
Graph Before Resolution
समस्या हल होने के बाद का ग्राफ़
Graph After Resolution

  1. अपने प्रोजेक्ट का पूरा डिपेंडेंसी ग्राफ़ दिखाएं.

    bazel mod graph

    <root> ([email protected])
├───[email protected]
│   └───[email protected]
├───[email protected]
│   └───[email protected] ...
├───[email protected]
│   ├───[email protected] ...
│   ├───[email protected]
│   │   ├───[email protected] ...
│   │   └───[email protected] ...
│   └───[email protected]
│       ├───[email protected] ...
│       └───[email protected] ...
└───[email protected]
    ├───[email protected] ...
    └───[email protected] ...

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

    bazel mod graph --include_unused --verbose

    <root> ([email protected])
├───[email protected]
│   └───[email protected]
├───[email protected]
│   └───[email protected] ...
├───[email protected]
│   ├───[email protected] ...
│   ├───[email protected]
│   │   ├───[email protected] ... (to 1.1.1, cause multiple_version_override)
│   │   ├───[email protected] ... (was 1.0.3, cause multiple_version_override)
│   │   └───[email protected] ...
│   └───[email protected]
│       ├───[email protected] ... (to 1.1.1, cause multiple_version_override)
│       ├───[email protected] ... (was 1.0.3, cause multiple_version_override)
│       └───[email protected] ...
└───[email protected]
    ├───[email protected] ... (was 1.0.3, cause multiple_version_override)
    ├───[email protected] ... (was 4.0.0, cause <root>, bazel_tools@_)
    ├───[email protected] (to 1.1.1, cause multiple_version_override)
    │   └───[email protected] ...
    └───[email protected] (to 5.0.0, cause <root>, bazel_tools@_)
        ├───[email protected] ... (to 1.1.1, cause multiple_version_override)
        └───[email protected] ... (was 1.0.3, cause multiple_version_override)

  3. कुछ खास मॉड्यूल से, डिपेंडेंसी ग्राफ़ को बड़ा करके दिखाएं.

    bazel mod graph --from rules_java --include_unused

    <root> ([email protected])
├───[email protected]
│   ├───[email protected]
│   ├───[email protected]
│   │   ├───[email protected] ... (unused)
│   │   ├───[email protected] ...
│   │   └───[email protected] ...
│   └───[email protected]
│       ├───[email protected] ... (unused)
│       ├───[email protected] ...
│       └───[email protected] ...
└╌╌[email protected] (unused)
    ├───[email protected] (unused)
    │   └───[email protected] ...
    └───[email protected]
        └───[email protected] ...

  4. अपने दो मॉड्यूल के बीच के सभी पाथ दिखाएं.

    bazel mod all_paths [email protected] --from rules_proto

    <root> ([email protected])
└╌╌[email protected]
    ├───[email protected]
    └───[email protected]
        └───[email protected] ...

  5. देखें कि आपका प्रोजेक्ट कुछ मॉड्यूल पर क्यों और कैसे निर्भर करता है.

    bazel mod explain @skylib1 --verbose --include_unused

    <root> ([email protected])
├───[email protected]
├───[email protected]
│   ├───[email protected]
│   │   └───[email protected] ... (was 1.0.3, cause multiple_version_override)
│   └───[email protected]
│       ├───[email protected] ... (was 1.0.3, cause multiple_version_override)
│       └───[email protected] ...
└───[email protected]
    ├───[email protected] ... (was 1.0.3, cause multiple_version_override)
    ├╌╌[email protected]
    │   └───[email protected] ... (was 1.0.3, cause multiple_version_override)
    └╌╌[email protected]
        ├───[email protected] ... (was 1.0.3, cause multiple_version_override)
        └───[email protected] ...

  6. अपने मॉड्यूल के रिपॉज़िटरी के मूल नियम देखें.

    bazel mod show_repo rules_cc stardoc

    ## [email protected]:
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"],
)

  7. देखें कि आपके डिपेंडेंसी ग्राफ़ में किन मॉड्यूल एक्सटेंशन का इस्तेमाल किया गया है.

    bazel mod graph --extension_info=usages

    <root> ([email protected])
├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains
├───[email protected] #
│   ├───$@@rules_java.5.0.0//java:extensions.bzl%toolchains
│   ├───[email protected] #
│   │   └───$@@rules_cc.0.0.1//bzlmod:extensions.bzl%cc_configure
│   └───[email protected]
│       └───[email protected] ...
└───[email protected]
    └───[email protected] ...

  8. देखें कि डिपेंडेंसी ग्राफ़ के हिस्से के तौर पर, कुछ खास एक्सटेंशन से कौनसी रिपॉज़िटरी जनरेट और इंपोर्ट की जाती हैं.

    bazel mod show_extension @@rules_java+5.0.0//java:extensions.bzl%toolchains

    <root> ([email protected])
├───$@@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)...
├───[email protected] #
│   └───$@@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)...
└───[email protected]
    └───[email protected] ...

  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@_, [email protected])
  -   remote_java_tools (imported by bazel_tools@_, [email protected])
  -   remote_java_tools_darwin (imported by bazel_tools@_, [email protected])
  -   remote_java_tools_linux (imported by bazel_tools@_, [email protected])
  -   remote_java_tools_windows (imported by bazel_tools@_, [email protected])
  -   remotejdk11_linux_aarch64_toolchain_config_repo (imported by [email protected])
  -   remotejdk11_linux_ppc64le_toolchain_config_repo (imported by [email protected])
...(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 [email protected] at [email protected]/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++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>