Bzlmod là tên mã của hệ thống phần phụ thuộc bên ngoài mới được giới thiệu trong Bazel 5.0. Công cụ này ra đời nhằm giải quyết một số vấn đề của hệ thống cũ mà không thể khắc phục dần dần một cách hiệu quả. Hãy xem phần Tuyên bố vấn đề trong tài liệu thiết kế ban đầu để biết thêm thông tin chi tiết.
Trong Bazel 5.0, Bzlmod không được bật theo mặc định; bạn cần chỉ định cờ --experimental_enable_bzlmod để các nội dung sau có hiệu lực. Như tên cờ cho thấy, tính năng này hiện đang thử nghiệm; các API và hành vi có thể thay đổi cho đến khi tính năng này ra mắt chính thức.
Để di chuyển dự án sang Bzlmod, hãy làm theo Hướng dẫn di chuyển Bzlmod. Bạn cũng có thể tìm thấy ví dụ về cách sử dụng Bzlmod trong kho lưu trữ ví dụ.
Mô-đun Bazel
Hệ thống phần phụ thuộc bên ngoài dựa trên WORKSPACE cũ tập trung vào
kho lưu trữ (hoặc kho lưu trữ), được tạo thông qua quy tắc kho lưu trữ (hoặc quy tắc kho lưu trữ).
Mặc dù kho lưu trữ vẫn là một khái niệm quan trọng trong hệ thống mới, nhưng mô-đun là các đơn vị cốt lõi của phần phụ thuộc.
Về cơ bản, mô-đun là một dự án Bazel có thể có nhiều phiên bản, mỗi phiên bản phát hành siêu dữ liệu về các mô-đun khác mà nó phụ thuộc vào. Điều này tương tự như các khái niệm quen thuộc trong các hệ thống quản lý phần phụ thuộc khác: cấu phần phần mềm Maven, gói npm, hộp Cargo, mô-đun Go, v.v.
Một mô-đun chỉ đơn giản là chỉ định các phần phụ thuộc bằng cặp name và version, thay vì các URL cụ thể trong WORKSPACE. Sau đó, các phần phụ thuộc sẽ được tra cứu trong cơ sở đăng ký Bazel; theo mặc định là Cơ sở đăng ký trung tâm Bazel. Trong không gian làm việc, mỗi mô-đun sẽ được chuyển thành một kho lưu trữ.
MODULE.bazel
Mỗi phiên bản của mỗi mô-đun đều có một tệp MODULE.bazel khai báo các phần phụ thuộc và siêu dữ liệu khác. Sau đây là một ví dụ cơ bản:
module(
name = "my-module",
version = "1.0",
)
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
Tệp MODULE.bazel phải nằm ở gốc của thư mục không gian làm việc (bên cạnh tệp WORKSPACE). Không giống như tệp WORKSPACE, bạn không cần chỉ định các phần phụ thuộc bắc cầu; thay vào đó, bạn chỉ nên chỉ định các phần phụ thuộc trực tiếp và các tệp MODULE.bazel của phần phụ thuộc sẽ được xử lý để tự động khám phá các phần phụ thuộc bắc cầu.
Tệp MODULE.bazel tương tự như tệp BUILD vì không hỗ trợ bất kỳ hình thức nào của luồng điều khiển; đồng thời, tệp này cũng cấm câu lệnh load. Các lệnh mà tệp MODULE.bazel hỗ trợ là:
module, để chỉ định siêu dữ liệu về mô-đun hiện tại, bao gồm tên, phiên bản, v.v.;bazel_dep, để chỉ định các phần phụ thuộc trực tiếp trên các mô-đun Bazel khác;- Các cơ chế ghi đè chỉ có thể được mô-đun gốc sử dụng (tức là không phải mô-đun đang được sử dụng làm phần phụ thuộc) để tuỳ chỉnh hành vi của một phần phụ thuộc trực tiếp hoặc bắc cầu nhất định:
- Các lệnh liên quan đến tiện ích mô-đun:
Định dạng phiên bản
Bazel có một hệ sinh thái đa dạng và các dự án sử dụng nhiều lược đồ phiên bản. Phổ biến nhất cho đến nay là SemVer, nhưng cũng có các dự án nổi bật sử dụng các lược đồ khác nhau như Abseil, các phiên bản dựa trên ngày, ví dụ: 20210324.2).
Vì lý do này, Bzlmod sử dụng phiên bản quy cách SemVer linh hoạt hơn. Các điểm khác biệt bao gồm:
- SemVer quy định rằng phần "bản phát hành" của phiên bản phải bao gồm 3 phân đoạn:
MAJOR.MINOR.PATCH. Trong Bazel, yêu cầu này được nới lỏng để số lượng phân đoạn bất kỳ được phép. - Trong SemVer, mỗi phân đoạn trong phần "phát hành" chỉ được là chữ số. Trong Bazel, thuộc tính này được nới lỏng để cho phép các chữ cái và ngữ nghĩa so sánh khớp với "giá trị nhận dạng" trong phần "phát hành trước".
- Ngoài ra, ngữ nghĩa của việc tăng phiên bản chính, phiên bản phụ và phiên bản bản vá sẽ không được thực thi. (Tuy nhiên, hãy xem phần cấp độ tương thích để biết chi tiết về cách chúng tôi biểu thị khả năng tương thích ngược.)
Mọi phiên bản SemVer hợp lệ đều là phiên bản mô-đun Bazel hợp lệ. Ngoài ra, hai phiên bản SemVer a và b so sánh a < b nếu và chỉ khi điều tương tự xảy ra khi so sánh dưới dạng phiên bản mô-đun Bazel.
Độ phân giải phiên bản
Vấn đề về phần phụ thuộc kim cương là một vấn đề thường gặp trong không gian quản lý phần phụ thuộc phiên bản. Giả sử bạn có biểu đồ phần phụ thuộc sau:
A 1.0
/ \
B 1.0 C 1.1
| |
D 1.0 D 1.1
Bạn nên sử dụng phiên bản D nào? Để giải quyết câu hỏi này, Bzlmod sử dụng thuật toán Lựa chọn phiên bản tối thiểu (MVS) được giới thiệu trong hệ thống mô-đun Go. MVS giả định rằng tất cả các phiên bản mới của một mô-đun đều có khả năng tương thích ngược và do đó, chỉ chọn phiên bản cao nhất do bất kỳ phần phụ thuộc nào chỉ định (trong ví dụ là D 1.1). Nó được gọi là "tối thiểu" vì D 1.1 ở đây là phiên bản tối thiểu có thể đáp ứng các yêu cầu của chúng ta; ngay cả khi D 1.2 trở lên tồn tại, chúng ta cũng không chọn các phiên bản đó. Điều này mang lại lợi ích bổ sung là lựa chọn phiên bản có độ chân thực cao và có thể tái tạo.
Việc phân giải phiên bản được thực hiện cục bộ trên máy của bạn, chứ không phải do sổ đăng ký thực hiện.
Mức độ tương thích
Xin lưu ý rằng giả định của MVS về khả năng tương thích ngược là khả thi vì đơn giản là giả định của MVS chỉ coi các phiên bản tương thích ngược của một mô-đun là một mô-đun riêng biệt. Theo SemVer, điều đó có nghĩa là A 1.x và A 2.x được coi là các mô-đun riêng biệt và có thể cùng tồn tại trong biểu đồ phần phụ thuộc đã phân giải. Điều này có thể xảy ra do phiên bản chính được mã hoá trong đường dẫn gói trong Go, do đó không có bất kỳ xung đột thời gian biên dịch hoặc thời gian liên kết nào.
Tại Bazel, chúng tôi không thể đảm bảo như vậy. Do đó, chúng ta cần một cách để biểu thị số "phiên bản chính" nhằm phát hiện các phiên bản không tương thích ngược. Số này được gọi là cấp độ tương thích và được chỉ định bởi từng phiên bản mô-đun trong lệnh module(). Khi có thông tin này, chúng ta có thể báo lỗi khi phát hiện thấy các phiên bản của cùng một mô-đun có nhiều mức độ tương thích tồn tại trong biểu đồ phần phụ thuộc đã phân giải.
Tên kho lưu trữ
Trong Bazel, mọi phần phụ thuộc bên ngoài đều có tên kho lưu trữ. Đôi khi, cùng một phần phụ thuộc có thể được sử dụng thông qua nhiều tên kho lưu trữ (ví dụ: cả @io_bazel_skylib và @bazel_skylib đều có nghĩa là Bazel skylib) hoặc cùng một tên kho lưu trữ có thể được sử dụng cho nhiều phần phụ thuộc trong nhiều dự án.
Trong Bzlmod, các kho lưu trữ có thể được tạo bằng các mô-đun Bazel và tiện ích mô-đun. Để giải quyết xung đột tên kho lưu trữ, chúng tôi đang sử dụng cơ chế ánh xạ kho lưu trữ trong hệ thống mới. Sau đây là hai khái niệm quan trọng:
Tên kho lưu trữ chuẩn hoá: Tên kho lưu trữ duy nhất trên toàn cầu cho mỗi kho lưu trữ. Đây sẽ là tên thư mục chứa kho lưu trữ.
Được tạo như sau (Cảnh báo: định dạng tên chuẩn hoá không phải là API mà bạn nên phụ thuộc vào, định dạng này có thể thay đổi bất cứ lúc nào):- Đối với kho lưu trữ mô-đun Bazel:
module_name~version
(Ví dụ.@bazel_skylib~1.0.3) - Đối với kho lưu trữ tiện ích mô-đun:
module_name~version~extension_name~repo_name
(Ví dụ.@rules_cc~0.0.1~cc_configure~local_config_cc)
- Đối với kho lưu trữ mô-đun Bazel:
Tên kho lưu trữ gốc: Tên kho lưu trữ sẽ dùng trong các tệp
BUILDvà.bzltrong một kho lưu trữ. Cùng một phần phụ thuộc có thể có tên hiển thị khác nhau trong các kho lưu trữ khác nhau.
Được xác định như sau:
Mỗi kho lưu trữ đều có một từ điển ánh xạ kho lưu trữ của các phần phụ thuộc trực tiếp, đây là bản đồ từ tên kho lưu trữ rõ ràng đến tên kho lưu trữ chuẩn.
Chúng ta sử dụng mối liên kết kho lưu trữ để phân giải tên kho lưu trữ khi tạo nhãn. Xin lưu ý rằng không có xung đột về tên kho lưu trữ chuẩn hoá và bạn có thể khám phá cách sử dụng tên kho lưu trữ rõ ràng bằng cách phân tích cú pháp tệp MODULE.bazel. Do đó, bạn có thể dễ dàng phát hiện và giải quyết xung đột mà không ảnh hưởng đến các phần phụ thuộc khác.
Phần phụ thuộc Strict
Định dạng thông số kỹ thuật phần phụ thuộc mới cho phép chúng tôi thực hiện các bước kiểm tra nghiêm ngặt hơn. Cụ thể, chúng tôi hiện thực thi việc một mô-đun chỉ có thể sử dụng các kho lưu trữ được tạo từ các phần phụ thuộc trực tiếp của mô-đun đó. Điều này giúp ngăn chặn các sự cố vô tình và khó gỡ lỗi khi có gì đó thay đổi trong biểu đồ phần phụ thuộc bắc cầu.
Các phần phụ thuộc nghiêm ngặt được triển khai dựa trên việc liên kết kho lưu trữ. Về cơ bản, bản đồ kho lưu trữ cho mỗi kho lưu trữ chứa tất cả phần phụ thuộc trực tiếp, mọi kho lưu trữ khác đều không hiển thị. Các phần phụ thuộc hiển thị của mỗi kho lưu trữ được xác định như sau:
- Kho lưu trữ mô-đun Bazel có thể xem tất cả kho lưu trữ được giới thiệu trong tệp
MODULE.bazelthông quabazel_depvàuse_repo. - Kho lưu trữ tiện ích mô-đun có thể xem tất cả các phần phụ thuộc hiển thị của mô-đun cung cấp tiện ích, cùng với tất cả các kho lưu trữ khác được tạo bởi cùng một tiện ích mô-đun.
Tổ chức quản lý tên miền
Bzlmod phát hiện các phần phụ thuộc bằng cách yêu cầu thông tin của các phần phụ thuộc đó từ hệ thống đăng ký Bazel. Cấu phần đăng ký Bazel chỉ đơn giản là một cơ sở dữ liệu của các mô-đun Bazel. Loại sổ đăng ký duy nhất được hỗ trợ là sổ đăng ký chỉ mục, đây là một thư mục cục bộ hoặc máy chủ HTTP tĩnh theo một định dạng cụ thể. Trong tương lai, chúng tôi dự định sẽ hỗ trợ thêm nhật ký mô-đun đơn. Đây chỉ là các kho lưu trữ git chứa nguồn và nhật ký của một dự án.
Chỉ mục đăng ký
Cấu phần đăng ký chỉ mục là một thư mục cục bộ hoặc máy chủ HTTP tĩnh chứa thông tin về danh sách các mô-đun, bao gồm trang chủ, người duy trì, tệp MODULE.bazel của mỗi phiên bản và cách tìm nạp nguồn của mỗi phiên bản. Đáng chú ý là tệp này không cần tự phân phát bản lưu trữ nguồn.
Cấu hình đăng ký chỉ mục phải tuân theo định dạng dưới đây:
/bazel_registry.json: Tệp JSON chứa siêu dữ liệu cho sổ đăng ký như:mirrors, chỉ định danh sách các bản sao phản chiếu để sử dụng cho bản lưu trữ nguồn.module_base_path, chỉ định đường dẫn cơ sở cho các mô-đun có loạilocal_repositorytrong tệpsource.json.
/modules: Thư mục chứa một thư mục con cho mỗi mô-đun trong đăng ký này./modules/$MODULE: Thư mục chứa một thư mục con cho mỗi phiên bản của mô-đun này, cũng như tệp sau:metadata.json: Tệp JSON chứa thông tin về mô-đun, với các trường sau:homepage: URL trang chủ của dự án.maintainers: Danh sách các đối tượng JSON, mỗi đối tượng tương ứng với thông tin của một người duy trì mô-đun trong sổ đăng ký. Xin lưu ý rằng giá trị này không nhất thiết giống với tác giả của dự án.versions: Danh sách tất cả phiên bản của mô-đun này có trong sổ đăng ký này.yanked_versions: Danh sách các phiên bản bị xoá của mô-đun này. Thao tác này hiện không hoạt động, nhưng trong tương lai, các phiên bản đã bị xoá sẽ bị bỏ qua hoặc gây ra lỗi.
/modules/$MODULE/$VERSION: Thư mục chứa các tệp sau:MODULE.bazel: TệpMODULE.bazelcủa phiên bản mô-đun này.source.json: Tệp JSON chứa thông tin về cách tìm nạp nguồn của phiên bản mô-đun này.- Loại mặc định là "tài liệu lưu trữ" với các trường sau:
url: URL của bản lưu trữ nguồn.integrity: Checksum Tính toàn vẹn của tài nguyên phụ của tệp lưu trữ.strip_prefix: Tiền tố thư mục cần loại bỏ khi trích xuất bản lưu trữ nguồn.patches: Danh sách các chuỗi, mỗi chuỗi đặt tên cho một tệp bản vá để áp dụng cho tệp lưu trữ đã trích xuất. Các tệp bản vá nằm trong thư mục/modules/$MODULE/$VERSION/patches.patch_strip: Tương tự như đối số--stripcủa bản vá Unix.
- Bạn có thể thay đổi loại này để sử dụng đường dẫn cục bộ với các trường sau:
type:local_pathpath: Đường dẫn cục bộ đến kho lưu trữ, được tính như sau:- Nếu đường dẫn là đường dẫn tuyệt đối, sẽ được sử dụng nguyên trạng.
- Nếu path là đường dẫn tương đối và
module_base_pathlà đường dẫn tuyệt đối, thì path sẽ được phân giải thành<module_base_path>/<path> - Nếu path và
module_base_pathđều là đường dẫn tương đối, thì path sẽ được phân giải thành<registry_path>/<module_base_path>/<path>. Cơ sở đăng ký phải được lưu trữ cục bộ và do--registry=file://<registry_path>sử dụng. Nếu không, Bazel sẽ báo lỗi.
- Loại mặc định là "tài liệu lưu trữ" với các trường sau:
patches/: Thư mục không bắt buộc chứa các tệp bản vá, chỉ được dùng khisource.jsoncó loại "lưu trữ".
Hệ thống đăng ký trung tâm Bazel
Bazel Central Registry (BCR) là một sổ đăng ký chỉ mục nằm tại bcr.bazel.build. Nội dung của lớp này được kho lưu trữ GitHub bazelbuild/bazel-central-registry hỗ trợ.
BCR do cộng đồng Bazel duy trì; những người đóng góp được hoan nghênh gửi yêu cầu lấy dữ liệu. Xem Chính sách và quy trình của Cơ quan đăng ký trung tâm của dự án Bazel.
Ngoài việc tuân theo định dạng của sổ đăng ký chỉ mục thông thường, BCR yêu cầu một tệp presubmit.yml cho mỗi phiên bản mô-đun (/modules/$MODULE/$VERSION/presubmit.yml). Tệp này chỉ định một số mục tiêu bản dựng và kiểm thử thiết yếu có thể dùng để kiểm tra tính hợp lệ của phiên bản mô-đun này, đồng thời được quy trình CI của BCR sử dụng để đảm bảo khả năng tương tác giữa các mô-đun trong BCR.
Chọn sổ đăng ký
Bạn có thể sử dụng cờ Bazel lặp lại --registry để chỉ định danh sách đăng ký yêu cầu các mô-đun, nhờ đó, bạn có thể thiết lập dự án để tìm nạp các phần phụ thuộc từ một bên thứ ba hoặc sổ đăng ký nội bộ. Các tổ chức quản lý tên miền cũ
được ưu tiên. Để thuận tiện, bạn có thể đặt danh sách cờ --registry vào tệp .bazelrc của dự án.
Tiện ích mô-đun
Tiện ích mô-đun cho phép bạn mở rộng hệ thống mô-đun bằng cách đọc dữ liệu đầu vào từ các mô-đun trên biểu đồ phần phụ thuộc, thực hiện logic cần thiết để phân giải các phần phụ thuộc và cuối cùng là tạo kho lưu trữ bằng cách gọi các quy tắc kho lưu trữ. Các macro này có chức năng tương tự như macro WORKSPACE hiện nay, nhưng phù hợp hơn khi sử dụng các mô-đun và các phần phụ thuộc bắc cầu.
Tiện ích mô-đun được xác định trong các tệp .bzl, giống như quy tắc repo hoặc macro WORKSPACE. Các mô-đun này không được gọi trực tiếp; thay vào đó, mỗi mô-đun có thể chỉ định các phần dữ liệu được gọi là thẻ để tiện ích đọc. Sau đó, sau khi giải quyết phiên bản mô-đun xong, các tiện ích mô-đun sẽ được chạy. Mỗi tiện ích được chạy một lần sau khi phân giải mô-đun (vẫn trước khi bất kỳ bản dựng nào thực sự xảy ra) và có thể đọc tất cả các thẻ thuộc về tiện ích đó trên toàn bộ biểu đồ phần phụ thuộc.
[ A 1.1 ]
[ * maven.dep(X 2.1) ]
[ * maven.pom(...) ]
/ \
bazel_dep / \ bazel_dep
/ \
[ B 1.2 ] [ C 1.0 ]
[ * maven.dep(X 1.2) ] [ * maven.dep(X 2.1) ]
[ * maven.dep(Y 1.3) ] [ * cargo.dep(P 1.1) ]
\ /
bazel_dep \ / bazel_dep
\ /
[ D 1.4 ]
[ * maven.dep(Z 1.4) ]
[ * cargo.dep(Q 1.1) ]
Trong biểu đồ phần phụ thuộc mẫu ở trên, A 1.1 và B 1.2, v.v. là các mô-đun Bazel; bạn có thể coi mỗi mô-đun là một tệp MODULE.bazel. Mỗi mô-đun có thể chỉ định một số
thẻ cho các phần mở rộng của mô-đun; ở đây, một số thẻ được chỉ định cho phần mở rộng "maven" và một số được chỉ định cho "hàng hoá". Khi biểu đồ phần phụ thuộc này được hoàn tất (ví dụ: có thể B 1.2 thực sự có bazel_dep trên D 1.3 nhưng đã được nâng cấp lên D 1.4 do C), các tiện ích "maven" sẽ chạy và đọc tất cả thẻ maven.*, sử dụng thông tin trong đó để quyết định tạo kho lưu trữ nào.
Tương tự như phần mở rộng "cargo".
Mức sử dụng tiện ích
Các tiện ích được lưu trữ trong chính các mô-đun Bazel, vì vậy, để sử dụng một tiện ích trong mô-đun, trước tiên, bạn cần thêm bazel_dep vào mô-đun đó, sau đó gọi hàm tích hợp use_extension để đưa tiện ích đó vào phạm vi. Hãy xem xét ví dụ sau đây, một đoạn mã từ tệp MODULE.bazel để sử dụng tiện ích "maven" giả định được xác định trong mô-đun rules_jvm_external:
bazel_dep(name = "rules_jvm_external", version = "1.0")
maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
Sau khi đưa tiện ích vào phạm vi, bạn có thể sử dụng cú pháp dấu chấm để chỉ định thẻ cho tiện ích đó. Xin lưu ý rằng các thẻ cần tuân theo giản đồ do các lớp thẻ tương ứng xác định (xem định nghĩa về phần mở rộng bên dưới). Sau đây là ví dụ về cách chỉ định một số thẻ maven.dep và maven.pom.
maven.dep(coord="org.junit:junit:3.0")
maven.dep(coord="com.google.guava:guava:1.2")
maven.pom(pom_xml="//:pom.xml")
Nếu tiện ích tạo các kho lưu trữ mà bạn muốn sử dụng trong mô-đun, hãy sử dụng lệnh use_repo để khai báo các kho lưu trữ đó. Điều này nhằm đáp ứng điều kiện phụ thuộc nghiêm ngặt và tránh xung đột tên kho lưu trữ cục bộ.
use_repo(
maven,
"org_junit_junit",
guava="com_google_guava_guava",
)
Các kho lưu trữ do một tiện ích tạo ra là một phần của API, vì vậy, từ các thẻ bạn đã chỉ định, bạn nên biết rằng tiện ích "maven" sẽ tạo một kho lưu trữ có tên là "org_junit_junit" và một kho lưu trữ có tên là "com_google_guava_guava". Với use_repo, bạn có thể tuỳ ý đổi tên chúng trong phạm vi mô-đun của mình, chẳng hạn như "guava" tại đây.
Định nghĩa phần mở rộng
Các tiện ích mô-đun được xác định tương tự như các quy tắc repo, sử dụng hàm module_extension.
Cả hai đều có một hàm triển khai; nhưng trong khi các quy tắc repo có một số thuộc tính, thì các tiện ích mô-đun có một số tag_class, mỗi tag_class có một số thuộc tính. Các lớp thẻ xác định giản đồ cho các thẻ mà tiện ích này sử dụng. Tiếp tục ví dụ về phần mở rộng "maven" giả định ở trên:
# @rules_jvm_external//:extensions.bzl
maven_dep = tag_class(attrs = {"coord": attr.string()})
maven_pom = tag_class(attrs = {"pom_xml": attr.label()})
maven = module_extension(
implementation=_maven_impl,
tag_classes={"dep": maven_dep, "pom": maven_pom},
)
Các nội dung khai báo này cho thấy rõ rằng bạn có thể chỉ định thẻ maven.dep và maven.pom bằng cách sử dụng giản đồ thuộc tính được xác định ở trên.
Hàm triển khai tương tự như macro WORKSPACE, ngoại trừ việc hàm này nhận được một đối tượng module_ctx, cho phép truy cập vào biểu đồ phần phụ thuộc và tất cả các thẻ liên quan. Sau đó, hàm triển khai sẽ gọi các quy tắc kho lưu trữ để tạo kho lưu trữ:
# @rules_jvm_external//:extensions.bzl
load("//:repo_rules.bzl", "maven_single_jar")
def _maven_impl(ctx):
coords = []
for mod in ctx.modules:
coords += [dep.coord for dep in mod.tags.dep]
output = ctx.execute(["coursier", "resolve", coords]) # hypothetical call
repo_attrs = process_coursier(output)
[maven_single_jar(**attrs) for attrs in repo_attrs]
Trong ví dụ trên, chúng ta sẽ xem qua tất cả mô-đun trong biểu đồ phần phụ thuộc (ctx.modules), mỗi mô-đun là một đối tượng bazel_module có trường tags hiển thị tất cả các thẻ maven.* trên mô-đun. Sau đó, chúng ta gọi tiện ích CLI
Coursier để liên hệ với Maven và thực hiện việc phân giải. Cuối cùng, chúng ta sử dụng kết quả phân giải để tạo một số kho lưu trữ bằng cách sử dụng quy tắc kho lưu trữ maven_single_jar giả định.