Правила
- java_binary
- java_import
- java_library
- java_test
- java_package_configuration
- java_plugin
- java_runtime
- java_toolchain
java_binary
java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
Создаёт Java архив ("jar-файл"), плюс оболочку командной строки с тем же именем, что и правило. Оболочка командной строки использует путь к классам, включающий, среди прочего, jar-файл для каждой библиотеки, от которой зависит двоичный файл. При выполнении оболочки командной строки любая непустая JAVABIN переменная среды будет иметь приоритет над версией, указанной через флаг Bazel --java_runtime_version.
Оболочка скрипта принимает несколько уникальных флагов. Список настраиваемых флагов и переменных среды, принимаемых оболочкой, см. в //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt.
Неявные целевые объекты вывода
-
name.jar: Java архив, содержащий файлы классов и другие ресурсы, соответствующие прямым зависимостям двоичного файла. -
name-src.jar: Архив, содержащий исходные файлы ("исходный jar-файл"). -
name_deploy.jar: Java архив, подходящий для развертывания (создаётся только при явном запросе).Построение целевого объекта
<name>_deploy.jarдля вашего правила создаёт автономный jar-файл с манифестом, позволяющим запустить его с помощью командыjava -jarили с помощью опции оболочки скрипта--singlejar. Использование оболочки скрипта предпочтительнееjava -jar, потому что оно также передаёт флаги JVM и опции для загрузки нативных библиотек.Jar-файл для развертывания содержит все классы, которые были бы найдены загрузчиком классов, который искал бы путь к классам из оболочки скрипта двоичного файла от начала до конца. Он также содержит нативные библиотеки, необходимые для зависимостей. Они автоматически загружаются в JVM во время выполнения.
Если ваш целевой объект указывает атрибут launcher, то вместо обычного JAR-файла _deploy.jar будет являться нативным двоичным файлом. Он будет содержать загрузчик плюс любые нативные (C++) зависимости вашего правила, все объединённые в один статический двоичный файл. Байты фактического jar-файла будут добавлены к этому нативному двоичному файлу, создавая один двоичный блок, содержащий как исполняемый файл, так и Java-код. Вы можете напрямую выполнить полученный jar-файл так же, как вы выполняете любой нативный двоичный файл.
-
name_deploy-src.jar: Архив, содержащий исходные файлы, собранные из транзитивного замыкания целевого объекта. Они будут соответствовать классам вdeploy.jar, за исключением случаев, когда jar-файлы не имеют соответствующего исходного jar-файла.
Хорошей практикой является использование имени исходного файла, являющегося основной точкой входа приложения (без расширения). Например, если ваша точка входа называется Main.java, то ваше имя может быть Main.
Атрибут deps не разрешён в правиле java_binary без srcs; такое правило требует атрибута main_class, предоставленного runtime_deps.
Следующий фрагмент кода иллюстрирует распространённую ошибку:
java_binary(
name = "DontDoThis",
srcs = [
...,
"GeneratedJavaFile.java", # a generated .java file
],
deps = [":generating_rule",], # rule that generates that file
)
Сделайте так вместо этого:
java_binary(
name = "DoThisInstead",
srcs = [
...,
":generating_rule",
],
)
Аргументы
| Атрибуты |
|---|
