Как обновить зависимость Maven от библиотеки на базе Bazel? - PullRequest
Новая
       5

Как обновить зависимость Maven от библиотеки на базе Bazel?

0 голосов
/ 10 января 2019

Моя библиотека поддерживает сборки Bazel и зависит от Maven Central. Пользователь моей библиотеки хочет использовать более новую версию зависимости с новыми переходными зависимостями . Как это можно сделать?

gRPC 1.17 зависит от Guava 26. Однако в Guava 27 добавлена ​​зависимость от com.google.guava:failureaccess. Обычно приложение, использующее gRPC, просто создает свой собственный native.maven_jar() с новой версией и отключает вызов gRPC для native.maven_jar(). Затем это «обновит» репозиторий @com_google_guava_guava, который затем будет использоваться как gRPC, так и приложением.

Но @com_google_guava_guava не включает информацию о зависимостях. Это обычно решается наличием Third_party java_library() s, которые объединяют транзитивные зависимости. Однако эти java_library() не могут быть изменены приложением.

Я считаю, что bind() решит эту проблему, так как gRPC может зависеть от //external:com_google_guava_guava, который может быть java_library(). Но bind() не рекомендуется.

Ответы [ 3 ]

0 голосов
/ 24 января 2019

Рассмотрите возможность переключения вашей библиотеки на использование java_import_external вместо maven_jar.

java_import_external target включает информацию о зависимостях и, таким образом, позволяет приложению заменять версию цели и ее транзитивные зависимости.

Просто не забудьте добавить if native.existing_rule(name) == None: перед тем, как вы определите @com_google_guava_guava, чтобы позволить пользователю вашей библиотеки определить его самостоятельно с более новой версией guava, которая обновила зависимости.

0 голосов
/ 16 апреля 2019

Обновление: rules_jvm_external - это новый набор правил команды Bazel для транзитивного извлечения и разрешения артефактов.

В этом случае файл WORKSPACE будет содержать что-то вроде этого: 

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

maven_install(
    artifacts = [
        "com.google.guava:guava:27.0.1-jre",
    ],
    repositories = [
        "https://jcenter.bintray.com",
    ]
)

Это автоматически разрешит и извлечет артефакты guava и failaccess. Затем в файле BUILD вы можете напрямую зависеть от Guava следующим образом: 

java_library(
    name = "my_jar",
    srcs = # ...
    deps = [
        "@maven//com_google_guava_guava",
    ],
)
0 голосов
/ 14 января 2019

Подумав немного об этом, я чувствую, что bind() может быть лучшим способом для grpc-java предложить это. Мне не известны какие-либо функции в существующих инструментах перехода Maven, которые могли бы сделать это проще.

Однако, если пользователь хочет сделать это без изменения grpc-java, он может:

  1. В WORKSPACE, переопределить com_google_guava_guava с local_repository(): 

    grpc_java_repositories(
    omit_com_google_guava = True,
)

maven_jar(
    name = "com_google_guava_guava_real",
    artifact = "com.google.guava:guava:27.0.1-jre",
    sha1 = "bd41a290787b5301e63929676d792c507bbc00ae",
)

maven_jar(
    name = "com_google_guava_failureaccess",
    artifact = "com.google.guava:failureaccess:1.0.1",
    sha1 = "1dcf1de382a0bf95a3d8b0849546c88bac1292c9",
)

local_repository(
    name = "com_google_guava_guava",
    path = "guava_27",
)

  2. Создать подотчет, который представляет совместимый java_library(): 

    mkdir -p guava_27/jar
echo > guava_27/WORKSPACE
cat > guava_27/jar/BUILD.bazel << EOF
java_library(
    name = "jar",
    visibility = ["//visibility:public"],
    exports = [
        "@com_google_guava_failureaccess//jar",
        "@com_google_guava_guava_real//jar",
    ],
)
EOF
...