Как разрешить зависимость во внешнем пакете workspace_file? - PullRequest
Новая
       14

Как разрешить зависимость во внешнем пакете workspace_file?

0 голосов
/ 04 июля 2019

Попытка использовать цель в build_file из внешнего пакета, импортированного через http_archive, у которого есть зависимости, определенные в рабочей области внешнего пакета через атрибут workspace_file, не удалась. Я использую Bazel 0.27.0 для тестирования Debian.

В документации говорится только о ссылках на цели в предоставленном build_file, но я не смог найти никакой информации о том, как можно ссылаться на зависимость, определенную в предоставленном workspace_file в предоставленном build_file.

Обычный синтаксис @stringtemplate3//jar не работает, но я не знаю, как добавить ссылку на импортированный архив, который согласно инструкции должен начинаться с @antlr3_runtimes.

Макет проекта выглядит следующим образом: 

├── antlr.BUILD
├── antlr.WORKSPACE
├── BUILD
├── external_dependency
│   └── src
│       └── main
│           └── java
│               └── bazel
│                   ├── BUILD
│                   └── Hello.java
├── LICENSE
└── WORKSPACE

Определение WORKSPACE выглядит следующим образом: 

workspace(name="bazel")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "antlr3_runtimes",
    sha256 = "d4f7d3c38c5523f8009ff37528e5797c81adb454be6acc9af507cfcb41f2016f",
    strip_prefix = "antlr3-master",
    urls = ["https://github.com/ibre5041/antlr3/archive/master.tar.gz"],
    build_file = "@//:antlr.BUILD",
    workspace_file = "@//:antlr.WORKSPACE",
)

Похоже, что workspace_file даже не анализируется. Сборка уже дает сбой, когда она пытается разрешить зависимости в пользовательском файле сборки.

Репро можно найти здесь: https://github.com/marcohu/bazel

bazel build //... показывает это сообщение об ошибке: 

ERROR: /home/user/.cache/bazel/_bazel_user/64492308e78c9898c41f12c18dd29b63/external/antlr3_runtimes/BUILD.bazel:43:1: no such package '@stringtemplate3//jar': The repository '@stringtemplate3' could not be resolved and referenced by '@antlr3_runtimes//:antlr3_tool'
ERROR: Analysis of target '//external_dependency/src/main/java/bazel:hello' failed; build aborted: no such package '@stringtemplate3//jar': The repository '@stringtemplate3' could not be resolved

Я сообщил об этом в трекере проблем Bazel, но он был отклонен с подсказкой опубликовать здесь.

Является ли этот вариант использования чем-то, что просто невозможно? Или я неправильно понял синтаксис?

Ответы [ 2 ]

0 голосов
/ 19 июля 2019

Bazel действительно поддерживает транзитивную выборку зависимостей jvm.https://github.com/bazelbuild/rules_jvm_external

WORKSPACE 

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

rules_jvm_external_tag = "2.0.1"

rules_jvm_external_sha = "55e8d3951647ae3dffde22b4f7f8dee11b3f70f3f89424713debd7076197eaca"

http_archive(
    name = "rules_jvm_external",
    sha256 = rules_jvm_external_sha,
    strip_prefix = "rules_jvm_external-%s" % rules_jvm_external_tag,
    url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % rules_jvm_external_tag,
)

load("@rules_jvm_external//:defs.bzl", "maven_install")

maven_install(
    name = "maven",
    artifacts = [
        "io.grpc:grpc-netty-shaded:1.22.1",
        "io.grpc:grpc-api:1.22.1",
        "io.grpc:grpc-testing:1.22.1",
        "io.grpc:grpc-core:1.22.1",
        "junit:junit:4.12",
    ],
    repositories = [
        "https://jcenter.bintray.com/",
        "https://repo1.maven.org/maven2",
    ],
)

BUILD 

...
java_library(
    name = "hyphenation-service",
    srcs = ["src/test/java/com/example/hyphenation/HyphenationServiceTest.java"],
    deps = ["@maven//:io_grpc_grpc_core"]
)
...

Пример репозитория https://github.com/mancini0/bazel-grpc-playground

0 голосов
/ 08 июля 2019

По крайней мере, на данный момент (я полагаю, это утверждение может измениться в будущих версиях), bazel напрямую не поддерживает переходные внешние зависимости. Файл WORKSPACE будет по-прежнему считываться даже в вашем случае, и если он будет содержать полностью нарушенный синтаксис, он все равно не будет работать, но он не будет "обработан", и вы можете (в настоящее время), например, загрузить из несуществующих меток или вызовите неопределенные функции и все равно не останетесь никого мудрее для вложенного WORKSPACE.

У вас есть два варианта:

  1. Повторите ваши вложенные зависимости (http_archive правила) в вашем "parent" / top WORKSPACE.

  2. Вы можете определить функцию (и) с соответствующими правилами репозитория, которые вы загружаете и вызываете в своем "parent" / top WORKSPACE.

...