Regras
- java_binary
- java_import
- java_library
- java_lite_proto_library
- java_proto_library
- java_test
- java_package_configuration
- java_plugin
- java_runtime
- java_toolchain
java_binary
java_binary(name, deps, srcs, data, resources, args, 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, output_licenses, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)
Cria um arquivo Java ("arquivo jar"), além de um script de shell do wrapper com o mesmo nome da regra. O script de shell do wrapper usa um caminho de classe que inclui, entre outras coisas, um arquivo jar para cada da qual o binário depende.
O script do wrapper aceita várias sinalizações exclusivas. Consulte
//src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt
para uma lista de sinalizações configuráveis e variáveis de ambiente aceitas pelo wrapper.
Destinos de saída implícitos
name.jar
: um arquivo Java, contendo os arquivos da classe e outros recursos que correspondem às dependências diretas do binário.name-src.jar
: um arquivo que contém as origens. garrafa).name_deploy.jar
: um arquivo Java adequado para implantação (somente criado se solicitado explicitamente).Como criar o destino
<name>_deploy.jar
para sua regra cria um arquivo jar independente com um manifesto que permite que ele seja executado com o o comandojava -jar
ou o--singlejar
do script de wrapper é a melhor opção. É preferível usar o script de wrapper em vez dejava -jar
porque ele também transmite as sinalizações da JVM e as opções para carregar bibliotecas nativas.O jar de implantação contém todas as classes que podem ser encontradas por um carregador de classe que pesquisou o caminho de classe a partir do script de wrapper do binário do início ao fim. Ela também contém as bibliotecas nativas necessárias para as dependências. Eles são carregados automaticamente para a JVM durante a execução.
Caso seu destino especifique uma tela de início em vez de ser um arquivo JAR normal, o _deploy.jar será um binário nativo. Ela conterá o inicializador e todas as dependências nativas (C++) do à sua regra, tudo vinculado a um binário estático. Os bytes do arquivo jar serão anexado a esse binário nativo, criando um único blob binário contendo os dois executável e o código Java. Você pode executar o arquivo jar resultante diretamente como você executa qualquer binário nativo.
name_deploy-src.jar
: um arquivo contendo as origens. coletados do fechamento transitivo do alvo. Eles corresponderão às classes dadeploy.jar
, exceto quando os jars não têm um jar de origem correspondente.
Um atributo deps
não é permitido em uma regra java_binary
sem
srcs
; essa regra exige
main_class
fornecida por
runtime_deps
.
O snippet de código a seguir ilustra um erro comum:
java_binary( name = "DontDoThis", srcs = [ ...,"GeneratedJavaFile.java"
, # a generated .java file ], deps = [":generating_rule",
], # rule that generates that file )
Em vez disso, faça o seguinte:
java_binary( name = "DoThisInstead", srcs = [ ..., ":generating_rule", ], )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. É recomendável usar o nome do arquivo de origem que é o ponto de entrada principal do aplicativo (menos a extensão). Por exemplo, se o ponto de entrada for chamado Main.java , seu nome poderá ser Main .
|
deps
|
deps em
Atributos típicos definidos pelo
a maioria das regras de build.
|
srcs
|
Arquivos de origem do tipo
Arquivos de origem do tipo
Regras: se a regra (normalmente
Esse argumento é quase sempre necessário, exceto se um
O atributo |
resources
|
Se os recursos forem especificados, eles serão empacotados no jar junto com o
Arquivos Os recursos podem ser arquivos de origem ou gerados. |
classpath_resources
|
Uma lista de recursos que precisam estar localizados na raiz da árvore Java. A configuração
único objetivo é oferecer suporte a bibliotecas de terceiros que exijam que os recursos sejam
encontrado no caminho de classe como exatamente |
create_executable
|
launcher ou main_class
estão definidos.
|
deploy_env
|
java_binary que representam a implantação
para este binário.
Defina este atributo ao compilar um plug-in que será carregado por outro
java_binary :A definição desse atributo exclui todas as dependências do o caminho de classe do ambiente de execução (e o jar de implantação) desse binário, que são compartilhados entre esse binário e os destinos especificados em deploy_env .
|
deploy_manifest_lines
|
META-INF/manifest.mf gerado para o
Meta de *_deploy.jar . O conteúdo deste atributo não está sujeito
para a substituição "Make variables".
|
javacopts
|
Essas opções do compilador são transmitidas para javac após as opções do compilador global. |
jvm_flags
|
O script de wrapper para um binário Java inclui uma definição de CLASSPATH
(para encontrar todos os jars dependentes) e invoca o interpretador Java correto.
A linha de comando gerada pelo script do wrapper inclui o nome do
a classe principal seguida por um Esse atributo não tem efeito em |
launcher
|
bin/java normal incluído no JDK.
O destino precisa ser um cc_binary . Qualquer cc_binary que
implementa
A API Java Invocation pode ser especificada como um valor para esse atributo.
Por padrão, o Bazel usa o inicializador normal do JDK (bin/java ou java.exe). A flag Observe que as dependências nativas (C++, SWIG, JNI) serão criadas de maneira diferente dependendo se você está usando o inicializador do JDK ou outro inicializador:
Ao usar qualquer inicializador diferente do inicializador padrão do JDK, o formato
das mudanças de saída |
main_class
|
main() para usar como ponto de entrada.
Se uma regra usar essa opção, não precisará de uma lista srcs=[...] .
Portanto, com esse atributo, é possível tornar um executável a partir de uma biblioteca Java que já
contém um ou mais métodos main() .
O valor desse atributo é um nome de classe, não um arquivo de origem. A classe precisa ser
Disponível no momento da execução: ele pode ser compilado por essa regra (de |
plugins
|
java_plugin especificado neste atributo será executado sempre que esta regra
é construído. Uma biblioteca também pode herdar plug-ins de dependências que usam
exported_plugins : Recursos
gerados pelo plug-in serão incluídos no jar resultante dessa regra.
|
resource_jars
|
|
resource_strip_prefix
|
Se especificado, esse prefixo de caminho é removido de todos os arquivos no |
runtime_deps
|
deps comum, eles vão aparecer no caminho de classe do tempo de execução, mas, ao contrário
e não no caminho de classe do tempo de compilação. As dependências necessárias apenas no ambiente de execução devem ser
listadas aqui. As ferramentas de análise de dependência devem ignorar os destinos que aparecem em ambos
runtime_deps e deps .
|
stamp
|
Os binários carimbos não são recriados, a menos que as dependências deles mudem. |
use_launcher
|
Se este atributo for definido como falso, o
atributo launcher e o relacionado
Sinalização |
use_testrunner
|
com.google.testing.junit.runner.BazelTestRunner ) como a
ponto de entrada principal de um programa Java e forneceremos a classe de teste
ao executor de testes como um valor de bazel.test_suite
propriedade do sistema.
Use-o para substituir o padrão
que é usar o executor de testes para
java_test regras,
e não o usará para regras java_binary . É improvável
você vai querer fazer isso. Um uso é para AllTest
chamadas por outra regra (para configurar um banco de dados
antes de executar os testes, por exemplo). O AllTest
regra deve ser declarada como java_binary , mas deve
usar o executor de testes como ponto de entrada principal.
O nome de uma classe do executor de testes pode ser substituído pelo atributo main_class .
|
java_import
java_import(name, deps, data, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, visibility)
Essa regra permite o uso de arquivos .jar
pré-compilados como
bibliotecas para java_library
e
java_binary
.
Exemplos
java_import( name = "maven_model", jars = [ "maven_model/maven-aether-provider-3.2.3.jar", "maven_model/maven-model-3.2.3.jar", "maven_model/maven-model-builder-3.2.3.jar", ], )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
deps
|
|
constraints
|
|
exports
|
|
jars
|
|
neverlink
|
tools.jar para qualquer item executado no
um JDK padrão.
|
proguard_specs
|
android_binary , dependendo dessa biblioteca.
Os arquivos incluídos aqui só podem ter regras idempotentes, como -dontnote, -dontwarn
presumanocolaterais e regras que começam com -keep. Outras opções só podem aparecer em
Proguard_specs de android_binary , para garantir mesclas não tautológicas.
|
runtime_deps
|
|
srcjar
|
|
java_library
java_library(name, deps, srcs, data, resources, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javacopts, licenses, neverlink, plugins, proguard_specs, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, visibility)
Essa regra compila e vincula origens em um arquivo .jar
.
Destinos de saída implícitos
libname.jar
: um arquivo Java que contém os arquivos da classe.libname-src.jar
: um arquivo que contém as origens. garrafa).
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
deps
|
deps em
Atributos típicos definidos pelo
a maioria das regras de build.
Os jars criados pelas regras de
Por outro lado, os destinos no atributo |
srcs
|
Arquivos de origem do tipo
Arquivos de origem do tipo
Regras: se a regra (normalmente
Esse argumento é quase sempre necessário, exceto se um
O atributo |
data
|
data em
Atributos típicos definidos pelo
a maioria das regras de build.
Ao criar um |
resources
|
Se os recursos forem especificados, eles serão empacotados no jar junto com o
Arquivos Os recursos podem ser arquivos de origem ou gerados. |
exported_plugins
|
java_plugin s (por exemplo, de anotação
processadores) para exportar para bibliotecas que dependem diretamente dessa biblioteca.
A lista especificada de |
exports
|
As regras de listagem aqui as tornarão disponíveis para regras pai, como se as mães
dependia dessas regras. Isso não é verdade para o
Resumo: uma regra X pode acessar o código em Y se houver uma dependência
caminho entre eles que começa com uma aresta
Suponha que A dependa de B e B dependa de C. Nesse caso,
C é uma dependência transitiva de A, então alterar as origens de C e recriar A vai
e recriar tudo corretamente. No entanto, A não poderá usar classes em C. Para permitir
que A precisa declarar C em O fechamento de bibliotecas exportadas está disponível para todas as regras mãe diretas. Dê uma olhada um pouco exemplo diferente: A depende de B, B depende de C e D e também exporta C, mas não D. Agora, A tem acesso a C, mas não a D. Agora, se C e D exportassem algumas bibliotecas, C' e D' respectivamente, A só pode acessar C' mas não D".
Importante: uma regra exportada não é uma dependência regular. Mantendo o exemplo anterior,
se B exportar C e também quiser usar C, deverá listá-lo no próprio
|
javacopts
|
Essas opções do compilador são transmitidas para javac após as opções do compilador global. |
neverlink
|
tools.jar para qualquer
em execução em um JDK padrão.
O Se a biblioteca de tempo de execução for diferente da biblioteca de compilação, será necessário garantir que ela difere apenas em locais em que o JLS proíbe os compiladores para inline (e que deve manter para todas as versões futuras do JLS). |
plugins
|
java_plugin especificado neste atributo será executado sempre que esta regra
é construído. Uma biblioteca também pode herdar plug-ins de dependências que usam
exported_plugins : Recursos
gerados pelo plug-in serão incluídos no jar resultante dessa regra.
|
proguard_specs
|
android_binary , dependendo dessa biblioteca.
Os arquivos incluídos aqui só podem ter regras idempotentes, como -dontnote, -dontwarn
presumanocolaterais e regras que começam com -keep. Outras opções só podem aparecer em
Proguard_specs de android_binary , para garantir mesclas não tautológicas.
|
resource_jars
|
|
resource_strip_prefix
|
Se especificado, esse prefixo de caminho é removido de todos os arquivos no |
runtime_deps
|
deps comum, eles vão aparecer no caminho de classe do tempo de execução, mas, ao contrário
e não no caminho de classe do tempo de compilação. As dependências necessárias apenas no ambiente de execução devem ser
listadas aqui. As ferramentas de análise de dependência devem ignorar os destinos que aparecem em ambos
runtime_deps e deps .
|
java_lite_proto_library
java_lite_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
java_lite_proto_library
gera código Java com base em arquivos .proto
.
deps
precisa apontar para regras proto_library
.
Exemplo:
java_library( name = "lib", deps = [":foo"], ) java_lite_proto_library( name = "foo", deps = [":bar"], ) proto_library( name = "bar", )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
deps
|
proto_library
para gerar código Java.
|
java_proto_library
java_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
java_proto_library
gera código Java com base em arquivos .proto
.
deps
precisa apontar para regras proto_library
.
Exemplo:
java_library( name = "lib", deps = [":foo_java_proto"], ) java_proto_library( name = "foo_java_proto", deps = [":foo_proto"], ) proto_library( name = "foo_proto", )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
deps
|
proto_library
para gerar código Java.
|
java_test
java_test(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, plugins, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)
Uma regra java_test()
compila um teste Java. Um teste é um wrapper binário em torno
código de teste. O método principal do executor de testes é invocado em vez da classe principal sendo compilada.
Destinos de saída implícitos
name.jar
: um arquivo Java.name_deploy.jar
: um arquivo Java adequado para implantação. (Criado somente se solicitado explicitamente.) Consulte a descriçãoname_deploy.jar
saída de java_binary para mais detalhes.
Consulte a seção sobre argumentos java_binary(). Esta regra também suporta todos os atributos comuns a todas as regras de teste (*_test).
Exemplos
java_library( name = "tests", srcs = glob(["*.java"]), deps = [ "//java/com/foo/base:testResources", "//java/com/foo/testing/util", ], ) java_test( name = "AllTests", size = "small", runtime_deps = [ ":tests", "//util/mysql", ], )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
deps
|
deps em
Atributos típicos definidos pelo
a maioria das regras de build.
|
srcs
|
Arquivos de origem do tipo
Arquivos de origem do tipo
Regras: se a regra (normalmente
Esse argumento é quase sempre necessário, exceto se um
O atributo |
resources
|
Se os recursos forem especificados, eles serão empacotados no jar junto com o
Arquivos Os recursos podem ser arquivos de origem ou gerados. |
classpath_resources
|
Uma lista de recursos que precisam estar localizados na raiz da árvore Java. A configuração
único objetivo é oferecer suporte a bibliotecas de terceiros que exijam que os recursos sejam
encontrado no caminho de classe como exatamente |
create_executable
|
launcher ou main_class
estão definidos.
|
deploy_manifest_lines
|
META-INF/manifest.mf gerado para o
Meta de *_deploy.jar . O conteúdo deste atributo não está sujeito
para a substituição "Make variables".
|
javacopts
|
Essas opções do compilador são transmitidas para javac após as opções do compilador global. |
jvm_flags
|
O script de wrapper para um binário Java inclui uma definição de CLASSPATH
(para encontrar todos os jars dependentes) e invoca o interpretador Java correto.
A linha de comando gerada pelo script do wrapper inclui o nome do
a classe principal seguida por um Esse atributo não tem efeito em |
launcher
|
bin/java normal incluído no JDK.
O destino precisa ser um cc_binary . Qualquer cc_binary que
implementa
A API Java Invocation pode ser especificada como um valor para esse atributo.
Por padrão, o Bazel usa o inicializador normal do JDK (bin/java ou java.exe). A flag Observe que as dependências nativas (C++, SWIG, JNI) serão criadas de maneira diferente dependendo se você está usando o inicializador do JDK ou outro inicializador:
Ao usar qualquer inicializador diferente do inicializador padrão do JDK, o formato
das mudanças de saída |
main_class
|
main() para usar como ponto de entrada.
Se uma regra usar essa opção, não precisará de uma lista srcs=[...] .
Portanto, com esse atributo, é possível tornar um executável a partir de uma biblioteca Java que já
contém um ou mais métodos main() .
O valor desse atributo é um nome de classe, não um arquivo de origem. A classe precisa ser
Disponível no momento da execução: ele pode ser compilado por essa regra (de |
plugins
|
java_plugin especificado neste atributo será executado sempre que esta regra
é construído. Uma biblioteca também pode herdar plug-ins de dependências que usam
exported_plugins : Recursos
gerados pelo plug-in serão incluídos no jar resultante dessa regra.
|
resource_jars
|
|
resource_strip_prefix
|
Se especificado, esse prefixo de caminho é removido de todos os arquivos no |
runtime_deps
|
deps comum, eles vão aparecer no caminho de classe do tempo de execução, mas, ao contrário
e não no caminho de classe do tempo de compilação. As dependências necessárias apenas no ambiente de execução devem ser
listadas aqui. As ferramentas de análise de dependência devem ignorar os destinos que aparecem em ambos
runtime_deps e deps .
|
stamp
|
Os binários carimbos não são recriados, a menos que as dependências deles mudem. |
test_class
|
Por padrão, se esse argumento não estiver definido, o modo legado será usado e o
argumentos de teste são usados no lugar. Definir a sinalização
Este atributo especifica o nome de uma classe Java a ser executada
nesse teste. É raro precisar definir isso. Se esse argumento for omitido,
ela será inferida usando a
Para JUnit3, a classe de teste precisa ser uma subclasse de
Esse atributo permite que várias regras |
use_launcher
|
Se este atributo for definido como falso, o
atributo launcher e o relacionado
Sinalização |
use_testrunner
|
com.google.testing.junit.runner.BazelTestRunner ) como a
ponto de entrada principal de um programa Java e forneceremos a classe de teste
ao executor de testes como um valor de bazel.test_suite
propriedade do sistema.
Use-o para substituir o padrão
que é usar o executor de testes para
java_test regras,
e não o usará para regras java_binary . É improvável
você vai querer fazer isso. Um uso é para AllTest
chamadas por outra regra (para configurar um banco de dados
antes de executar os testes, por exemplo). O AllTest
regra deve ser declarada como java_binary , mas deve
usar o executor de testes como ponto de entrada principal.
O nome de uma classe do executor de testes pode ser substituído pelo atributo main_class .
|
java_package_configuration
java_package_configuration(name, data, compatible_with, deprecation, distribs, features, javacopts, licenses, packages, restricted_to, tags, target_compatible_with, testonly, visibility)
Configuração para aplicar a um conjunto de pacotes.
As configurações podem ser adicionadas
java_toolchain.javacopts
s.
Exemplo:
java_package_configuration( name = "my_configuration", packages = [":my_packages"], javacopts = ["-Werror"], ) package_group( name = "my_packages", packages = [ "//com/my/project/...", "-//com/my/project/testing/...", ], ) java_toolchain( ..., package_configuration = [ ":my_configuration", ] )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
data
|
|
javacopts
|
|
packages
|
package_group s
a configuração deve ser aplicada.
|
java_plugin
java_plugin(name, deps, srcs, data, resources, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_jars, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, visibility)
java_plugin
define plug-ins para o compilador Java executado pelo Bazel. No momento,
os únicos tipos de plug-ins compatíveis são os processadores de anotações. Uma java_library
ou
A regra java_binary
pode executar plug-ins dependendo deles pela plugins
. Um java_library
também pode exportar automaticamente plug-ins para bibliotecas que
depender diretamente dele usando
exported_plugins
.
Destinos de saída implícitos
libname.jar
: um arquivo Java.
Os argumentos são idênticos a java_library
, exceto
para adicionar o argumento processor_class
.
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
deps
|
deps em
Atributos típicos definidos pelo
a maioria das regras de build.
Os jars criados pelas regras de
Por outro lado, os destinos no atributo |
srcs
|
Arquivos de origem do tipo
Arquivos de origem do tipo
Regras: se a regra (normalmente
Esse argumento é quase sempre necessário, exceto se um
O atributo |
data
|
data em
Atributos típicos definidos pelo
a maioria das regras de build.
Ao criar um |
resources
|
Se os recursos forem especificados, eles serão empacotados no jar junto com o
Arquivos Os recursos podem ser arquivos de origem ou gerados. |
generates_api
|
Se uma regra usar um processador de anotações que gera uma API, outras regras dependendo dele, poderá consultar o código gerado somente se as as ações de compilação são programadas após a regra geradora. Isso instrui o Bazel a introduzir restrições de programação ao --java_header_compilation está ativado. AVISO: este atributo afeta o build performance, use apenas se necessário. |
javacopts
|
Essas opções do compilador são transmitidas para javac após as opções do compilador global. |
neverlink
|
tools.jar para qualquer
em execução em um JDK padrão.
O Se a biblioteca de tempo de execução for diferente da biblioteca de compilação, será necessário garantir que ela difere apenas em locais em que o JLS proíbe os compiladores para inline (e que deve manter para todas as versões futuras do JLS). |
output_licenses
|
common attributes
.
|
plugins
|
java_plugin especificado neste atributo será executado sempre que esta regra
é construído. Uma biblioteca também pode herdar plug-ins de dependências que usam
exported_plugins : Recursos
gerados pelo plug-in serão incluídos no jar resultante dessa regra.
|
processor_class
|
|
proguard_specs
|
android_binary , dependendo dessa biblioteca.
Os arquivos incluídos aqui só podem ter regras idempotentes, como -dontnote, -dontwarn
presumanocolaterais e regras que começam com -keep. Outras opções só podem aparecer em
Proguard_specs de android_binary , para garantir mesclas não tautológicas.
|
resource_jars
|
|
resource_strip_prefix
|
Se especificado, esse prefixo de caminho é removido de todos os arquivos no |
java_runtime
java_runtime(name, srcs, compatible_with, deprecation, distribs, features, hermetic_srcs, java, java_home, lib_modules, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
Especifica a configuração para um ambiente de execução Java.
Exemplo:
java_runtime( name = "jdk-9-ea+153", srcs = glob(["jdk9-ea+153/**"]), java_home = "jdk9-ea+153", )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
srcs
|
|
hermetic_srcs
|
|
java
|
|
java_home
|
srcs e java precisam estar vazios.
|
lib_modules
|
|
java_toolchain
java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_with, deprecation, deps_checker, distribs, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_workers, javacopts, jvm_opts, licenses, oneversion, oneversion_whitelist, package_configuration, proguard_allowlister, resourcejar, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, tools, turbine_data, turbine_jvm_opts, visibility, xlint)
Especifica a configuração do compilador Java. O conjunto de ferramentas a ser usado pode ser alterado por meio de o argumento --java_dataset. Normalmente, você não deve escrever esse tipo de regra, a menos que queira ajustar seu compilador Java.
Exemplos
Um exemplo simples seria:
java_toolchain( name = "toolchain", source_version = "7", target_version = "7", bootclasspath = ["//tools/jdk:bootclasspath"], xlint = [ "classfile", "divzero", "empty", "options", "path" ], javacopts = [ "-g" ], javabuilder = ":JavaBuilder_deploy.jar", )
Argumentos
Atributos | |
---|---|
name |
Um nome exclusivo para o destino. |
android_lint_data
|
|
android_lint_jvm_opts
|
|
android_lint_opts
|
|
android_lint_package_configuration
|
|
android_lint_runner
|
|
bootclasspath
|
|
deps_checker
|
|
forcibly_disable_header_compilation
|
|
genclass
|
|
header_compiler
|
|
header_compiler_direct
|
Esta ferramenta não é compatível com o processamento de anotações. |
ijar
|
|
jacocorunner
|
|
java_runtime
|
|
javabuilder
|
|
javabuilder_data
|
|
javabuilder_jvm_opts
|
|
javac_supports_multiplex_workers
|
|
javac_supports_workers
|
|
javacopts
|
|
jvm_opts
|
|
oneversion
|
|
oneversion_whitelist
|
|
package_configuration
|
|
proguard_allowlister
|
|
resourcejar
|
|
singlejar
|
|
source_version
|
|
target_version
|
|
timezone_data
|
|
tools
|
|
turbine_data
|
|
turbine_jvm_opts
|
|
xlint
|
|