As inscrições e a CFP da BaselCon 2025 já estão abertas!

Esta página foi traduzida pela API Cloud Translation.

Regras do Java

Informar um problema Ver fonte Nightly · 8.3 · 8.2 · 8.1 ·

Regras

java_binary
java_import
java_library
java_test
java_package_configuration
java_plugin
java_runtime
java_single_jar
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, env, exec_compatible_with, exec_group_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, package_metadata, plugins, 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") e um script shell de wrapper com o mesmo nome da regra. O script shell wrapper usa um classpath que inclui, entre outras coisas, um arquivo JAR para cada biblioteca de que o binário depende. Ao executar o script shell de wrapper, qualquer variável de ambiente JAVABIN não vazia terá precedência sobre a versão especificada pela flag --java_runtime_version do Bazel.

O script wrapper aceita várias flags exclusivas. Consulte java_stub_template.txt para conferir uma lista de flags configuráveis e variáveis de ambiente aceitas pelo wrapper.

Metas de saída implícitas

name.jar: um arquivo Java que contém os arquivos de classe e outros recursos correspondentes às dependências diretas do binário.
name-src.jar: um arquivo que contém as fontes ("source jar").
name_deploy.jar: um arquivo Java adequado para implantação (criado somente se solicitado explicitamente).
A criação da meta <name>_deploy.jar para sua regra cria um arquivo jar independente com um manifesto que permite a execução com o comando java -jar ou com a opção --singlejar do script de wrapper. É melhor usar o script de wrapper do que java -jar porque ele também transmite as flags da JVM e as opções para carregar bibliotecas nativas.

O JAR de implantação contém todas as classes que seriam encontradas por um carregador de classes que pesquisou o classpath do script wrapper do binário do início ao fim. Ele também contém as bibliotecas nativas necessárias para dependências. Elas são carregadas automaticamente na JVM durante a execução.

Se o destino especificar um atributo launcher, em vez de ser um arquivo JAR normal, o _deploy.jar será um binário nativo. Ele vai conter o iniciador e todas as dependências nativas (C++) da sua regra, todos vinculados a um binário estático. Os bytes do arquivo jar real serão anexados a esse binário nativo, criando um único blob binário que contém o executável e o código Java. Você pode executar o arquivo JAR resultante diretamente como faria com qualquer binário nativo.
name_deploy-src.jar: um arquivo que contém as fontes coletadas do fechamento transitivo do destino. Elas corresponderão às classes no deploy.jar, exceto quando os jars não tiverem um jar de origem correspondente.

É recomendável usar o nome do arquivo de origem que é o principal ponto de entrada do aplicativo (sem a extensão). Por exemplo, se o ponto de entrada for chamado de Main.java, o nome poderá ser Main.

Um atributo deps não é permitido em uma regra java_binary sem srcs. Uma regra desse tipo exige um main_class fornecido 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`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos. O padrão é `[]`. A lista de outras bibliotecas a serem vinculadas ao destino. Consulte comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build.
`srcs`	Lista de rótulos. O padrão é `[]`. A lista de arquivos de origem processados para criar o destino. Esse atributo é quase sempre obrigatório. Confira as exceções abaixo. Os arquivos de origem do tipo `.java` são compilados. No caso de arquivos `.java` gerados, é recomendável colocar o nome da regra de geração aqui em vez do nome do arquivo em si. Isso não apenas melhora a legibilidade, mas também torna a regra mais resiliente a mudanças futuras: se a regra de geração gerar arquivos diferentes no futuro, basta corrigir um lugar: o `outs` da regra de geração. Não liste a regra de geração em `deps` porque ela não faz nada. Os arquivos de origem do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos `.java` com uma genrule. Regras: se a regra (normalmente `genrule` ou `filegroup`) gerar qualquer um dos arquivos listados acima, eles serão usados da mesma forma que os arquivos de origem. Esse argumento é quase sempre obrigatório, exceto se um atributo `main_class` especificar uma classe no classpath de tempo de execução ou se você especificar o argumento `runtime_deps`.
`data`	Lista de rótulos. O padrão é `[]`. A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte comentários gerais sobre `data` em Atributos típicos definidos pela maioria das regras de build.
`resources`	Lista de rótulos. O padrão é `[]`. Uma lista de arquivos de dados a serem incluídos em um jar Java. Os recursos podem ser arquivos de origem ou gerados. Se os recursos forem especificados, eles serão agrupados no jar junto com os arquivos `.class` comuns produzidos pela compilação. O local dos recursos dentro do arquivo jar é determinado pela estrutura do projeto. Primeiro, o Bazel procura o layout de diretório padrão (um diretório "src" seguido por um neto "resources"). Se não for encontrado, o Bazel vai procurar o diretório mais alto chamado "java" ou "javatests". Por exemplo, se um recurso estiver em `<workspace root>/x/java/y/java/z`, o caminho dele será `y/java/z`. Essa heurística não pode ser substituída. No entanto, o atributo `resource_strip_prefix` pode ser usado para especificar um diretório alternativo específico para arquivos de recursos.
`add_exports`	Lista de strings. O padrão é `[]`. Permite que a biblioteca acesse o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-exports=.
`add_opens`	Lista de strings. O padrão é `[]`. Permite que essa biblioteca acesse de forma reflexiva o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-opens=.
`bootclasspath`	Rótulo; o padrão é `None` API restrita, não use!
`classpath_resources`	Lista de rótulos. O padrão é `[]`. NÃO USE ESTA OPÇÃO A MENOS QUE NÃO HAJA OUTRA FORMA Uma lista de recursos que precisam estar na raiz da árvore Java. O único propósito desse atributo é oferecer suporte a bibliotecas de terceiros que exigem que os recursos sejam encontrados no classpath exatamente como `"myconfig.xml"`. Ele só é permitido em binários e não em bibliotecas, devido ao risco de conflitos de namespace.
`create_executable`	Booleano; o padrão é `True` obsoleto: use `java_single_jar`.
`deploy_env`	Lista de rótulos. O padrão é `[]`. Uma lista de outros destinos `java_binary` que representam o ambiente de implantação para este binário. Defina esse atributo ao criar um plug-in que será carregado por outro `java_binary`. Definir esse atributo exclui todas as dependências do classpath de tempo de execução (e o jar de implantação) desse binário que são compartilhadas entre esse binário e os destinos especificados em `deploy_env`.
`deploy_manifest_lines`	Lista de strings. O padrão é `[]`. Uma lista de linhas a serem adicionadas ao arquivo `META-INF/manifest.mf` gerado para a meta `_deploy.jar`. O conteúdo desse atributo não* está sujeito à substituição de "Criar variável".
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para este binário. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne. Essas opções são transmitidas para o javac depois das opções globais.
`jvm_flags`	Lista de strings. O padrão é `[]`. Uma lista de flags a serem incorporadas no script de wrapper gerado para executar este binário. Sujeito à substituição de $(location) e "Criar variável" e à tokenização do shell Bourne. 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 wrapper inclui o nome da classe principal seguido por um `"$@"` para que você possa transmitir outros argumentos após o nome da classe. No entanto, os argumentos destinados à análise pela JVM precisam ser especificados antes do nome da classe na linha de comando. O conteúdo de `jvm_flags` é adicionado ao script wrapper antes da listagem do nome da classe. Esse atributo não tem efeito nas saídas de `*_deploy.jar`.
`launcher`	Rótulo; o padrão é `None` Especifique um binário que será usado para executar seu programa Java em vez do programa `bin/java` normal incluído no JDK. O destino precisa ser um `cc_binary`. Qualquer `cc_binary` que implemente a API Java Invocation pode ser especificado como um valor para esse atributo. Por padrão, o Bazel usa o inicializador normal do JDK (bin/java ou java.exe). A flag `--java_launcher` relacionada do Bazel afeta apenas os destinos `java_binary` e `java_test` que não especificaram um atributo `launcher`. As dependências nativas (C++, SWIG, JNI) são criadas de maneira diferente dependendo se você está usando o iniciador do JDK ou outro: Se você estiver usando o iniciador normal do JDK (o padrão), as dependências nativas serão criadas como uma biblioteca compartilhada chamada `{name}_nativedeps.so`, em que `{name}` é o atributo `name` dessa regra java_binary. O código não usado não é removido pelo vinculador nessa configuração. Se você estiver usando outro iniciador, as dependências nativas (C++) serão vinculadas estaticamente a um binário chamado `{name}_nativedeps`, em que `{name}` é o atributo `name` dessa regra java_binary. Nesse caso, o vinculador remove do binário resultante qualquer código que considere não utilizado. Isso significa que qualquer código C++ acessado apenas via JNI não será vinculado, a menos que o destino `cc_library` especifique `alwayslink = True`. Ao usar um iniciador diferente do padrão do JDK, o formato da saída `*_deploy.jar` muda. Consulte a documentação principal de java_binary para mais detalhes.
`main_class`	String; o padrão é `""` Nome da classe com o método `main()` a ser usado como ponto de entrada. Se uma regra usar essa opção, ela não precisará de uma lista `srcs=[...]`. Assim, com esse atributo, é possível criar um executável 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 estar disponível no tempo de execução: ela pode ser compilada por essa regra (de `srcs`) ou fornecida por dependências diretas ou transitivas (por `runtime_deps` ou `deps`). Se a classe não estiver disponível, o binário vai falhar no tempo de execução. Não há verificação no tempo de build.
`neverlink`	Booleano; o padrão é `False`
`plugins`	Lista de rótulos. O padrão é `[]`. Plug-ins do compilador Java para serem executados no tempo de compilação. Cada `java_plugin` especificado nesse atributo será executado sempre que a regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`resource_strip_prefix`	String; o padrão é `""` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho será removido de todos os arquivos no atributo `resources`. É um erro se um arquivo de recursos não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java dos arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.
`runtime_deps`	Lista de rótulos. O padrão é `[]`. Bibliotecas a serem disponibilizadas apenas para o binário final ou para teste no momento da execução. Assim como os `deps` comuns, eles aparecem no caminho de classe de execução, mas não no caminho de classe de compilação. As dependências necessárias apenas no tempo de execução devem ser listadas aqui. As ferramentas de análise de dependências precisam ignorar destinos que aparecem em `runtime_deps` e `deps`.
`stamp`	Número inteiro. O padrão é `-1`. Determina se as informações de build serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre adicione as informações de build ao binário, mesmo em builds `--nostamp`. Evite essa configuração, já que ela pode encerrar o armazenamento em cache remoto para o binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitua as informações de build por valores constantes. Isso oferece um bom cache de resultados de build. `stamp = -1`: o embedding de informações de build é controlado pela flag `--[no]stamp`. Os binários carimbados não são recriados, a menos que as dependências mudem.
`use_launcher`	Booleano; o padrão é `True` Indica se o binário deve usar um iniciador personalizado. Se esse atributo for definido como "false", o atributo launcher e a flag `--java_launcher` relacionada serão ignorados para essa meta.
`use_testrunner`	Booleano; o padrão é `False` Use a classe do executor de testes (por padrão, `com.google.testing.junit.runner.BazelTestRunner`) como o ponto de entrada principal de um programa Java e forneça a classe de teste ao executor como um valor da propriedade do sistema `bazel.test_suite`. É possível usar isso para substituir o comportamento padrão, que é usar o executor de testes para regras `java_test`, e não usá-lo para regras `java_binary`. É improvável que você queira fazer isso. Um uso é para regras `AllTest` invocadas por outra regra (para configurar um banco de dados antes de executar os testes, por exemplo). A regra `AllTest` precisa ser declarada como um `java_binary`, mas ainda usa o executor de testes como ponto de entrada principal. O nome de uma classe de executor de teste pode ser substituído com o atributo `main_class`.

java_import

Ver origem da regra

java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, package_metadata, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)

Essa regra permite o uso de arquivos .jar pré-compilados como bibliotecas para regras 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`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos. O padrão é `[]`. A lista de outras bibliotecas a serem vinculadas ao destino. Consulte java_library.deps.
`data`	Lista de rótulos. O padrão é `[]`. A lista de arquivos necessários para essa regra no tempo de execução.
`add_exports`	Lista de strings. O padrão é `[]`. Permite que a biblioteca acesse o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-exports=.
`add_opens`	Lista de strings. O padrão é `[]`. Permite que essa biblioteca acesse de forma reflexiva o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-opens=.
`constraints`	Lista de strings. O padrão é `[]`. Restrições extras impostas a essa regra como uma biblioteca Java.
`exports`	Lista de rótulos. O padrão é `[]`. Destinos a serem disponibilizados para os usuários dessa regra. Consulte java_library.exports.
`jars`	Lista de marcadores; obrigatório A lista de arquivos JAR fornecidos para destinos Java que dependem desse destino.
`neverlink`	Booleano; o padrão é `False` Use essa biblioteca apenas para compilação, não no ambiente de execução. Isso é útil se a biblioteca for fornecida pelo ambiente de execução durante a execução. Exemplos de bibliotecas como essa são APIs de ambiente de desenvolvimento integrado para plug-ins de ambiente de desenvolvimento integrado ou `tools.jar` para qualquer coisa executada em um JDK padrão.
`proguard_specs`	Lista de rótulos. O padrão é `[]`. Arquivos a serem usados como especificação do Proguard. Eles descrevem o conjunto de especificações a serem usadas pelo ProGuard. Se especificados, eles serão adicionados a qualquer destino `android_binary` que dependa dessa biblioteca. Os arquivos incluídos aqui precisam ter apenas regras idempotentes, ou seja, -dontnote, -dontwarn, assumenosideeffects e regras que começam com -keep. Outras opções só podem aparecer em proguard_specs do `android_binary` para garantir fusões não tautológicas.
`runtime_deps`	Lista de rótulos. O padrão é `[]`. Bibliotecas a serem disponibilizadas apenas para o binário final ou para teste no momento da execução. Consulte java_library.runtime_deps.
`srcjar`	Rótulo; o padrão é `None` Um arquivo JAR que contém o código-fonte dos arquivos JAR compilados.

java_library

Ver origem da regra

java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, package_metadata, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)

Essa regra compila e vincula fontes em um arquivo .jar.

Saídas implícitas

libname.jar: um arquivo Java que contém os arquivos de classe.
libname-src.jar: um arquivo que contém as fontes ("source jar").

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos. O padrão é `[]`. A lista de bibliotecas a serem vinculadas a esta biblioteca. Consulte comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Os jars criados pelas regras `java_library` listadas em `deps` estarão no classpath de tempo de compilação dessa regra. Além disso, o fechamento transitivo de `deps`, `runtime_deps` e `exports` estará no classpath de tempo de execução. Por outro lado, os destinos no atributo `data` são incluídos nos runfiles, mas não no classpath de tempo de compilação nem de execução.
`srcs`	Lista de rótulos. O padrão é `[]`. A lista de arquivos de origem processados para criar o destino. Esse atributo é quase sempre obrigatório. Confira as exceções abaixo. Os arquivos de origem do tipo `.java` são compilados. No caso de arquivos `.java` gerados, é recomendável colocar o nome da regra de geração aqui em vez do nome do arquivo em si. Isso não apenas melhora a legibilidade, mas também torna a regra mais resiliente a mudanças futuras: se a regra de geração gerar arquivos diferentes no futuro, basta corrigir um lugar: o `outs` da regra de geração. Não liste a regra de geração em `deps` porque ela não faz nada. Os arquivos de origem do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos `.java` com uma genrule. Regras: se a regra (normalmente `genrule` ou `filegroup`) gerar qualquer um dos arquivos listados acima, eles serão usados da mesma forma que os arquivos de origem. Os arquivos de origem do tipo `.properties` são tratados como recursos. Todos os outros arquivos serão ignorados, desde que haja pelo menos um arquivo de um tipo descrito acima. Caso contrário, um erro será gerado. Esse argumento é quase sempre obrigatório, exceto se você especificar o argumento `runtime_deps`.
`data`	Lista de rótulos. O padrão é `[]`. A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte comentários gerais sobre `data` em Atributos típicos definidos pela maioria das regras de build. Ao criar um `java_library`, o Bazel não coloca esses arquivos em nenhum lugar. Se os arquivos `data` forem gerados, o Bazel os gera. Ao criar um teste que depende desse `java_library`, o Bazel copia ou vincula os arquivos `data` à área de arquivos de execução.
`resources`	Lista de rótulos. O padrão é `[]`. Uma lista de arquivos de dados a serem incluídos em um jar Java. Os recursos podem ser arquivos de origem ou gerados. Se os recursos forem especificados, eles serão agrupados no jar junto com os arquivos `.class` comuns produzidos pela compilação. O local dos recursos dentro do arquivo jar é determinado pela estrutura do projeto. Primeiro, o Bazel procura o layout de diretório padrão (um diretório "src" seguido por um neto "resources"). Se não for encontrado, o Bazel vai procurar o diretório mais alto chamado "java" ou "javatests". Por exemplo, se um recurso estiver em `<workspace root>/x/java/y/java/z`, o caminho dele será `y/java/z`. Essa heurística não pode ser substituída. No entanto, o atributo `resource_strip_prefix` pode ser usado para especificar um diretório alternativo específico para arquivos de recursos.
`add_exports`	Lista de strings. O padrão é `[]`. Permite que a biblioteca acesse o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-exports=.
`add_opens`	Lista de strings. O padrão é `[]`. Permite que essa biblioteca acesse de forma reflexiva o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-opens=.
`bootclasspath`	Rótulo; o padrão é `None` API restrita, não use!
`exported_plugins`	Lista de rótulos. O padrão é `[]`. A lista de `java_plugin`s (por exemplo, processadores de anotações) a serem exportados para bibliotecas que dependem diretamente desta biblioteca. A lista especificada de `java_plugin`s será aplicada a qualquer biblioteca que dependa diretamente dessa biblioteca, como se ela tivesse declarado explicitamente esses rótulos em `plugins`.
`exports`	Lista de rótulos. O padrão é `[]`. Bibliotecas exportadas. Listar regras aqui as disponibiliza para regras principais, como se elas dependessem explicitamente dessas regras. Isso não é verdade para `deps` regulares (não exportados). Resumo: uma regra X pode acessar o código em Y se houver um caminho de dependência entre eles que comece com uma aresta `deps` seguida por zero ou mais arestas `exports`. Vamos ver alguns exemplos para ilustrar isso. Suponha que A dependa de B e que B dependa de C. Nesse caso, C é uma dependência transitiva de A. Portanto, mudar as fontes de C e reconstruir A vai reconstruir tudo corretamente. No entanto, A não poderá usar classes em C. Para permitir isso, A precisa declarar C no `deps` ou B pode facilitar para A (e qualquer coisa que dependa de A) declarando C no atributo `exports` de B. O fechamento de bibliotecas exportadas está disponível para todas as regras principais diretas. Um exemplo um pouco 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ó poderia acessar C', mas não D'. Importante: uma regra exportada não é uma dependência regular. Seguindo o exemplo anterior, se B exporta C e também quer usar C, ele precisa listar C no próprio `deps`.
`javabuilder_jvm_flags`	Lista de strings. O padrão é `[]`. API restrita, não use!
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esta biblioteca. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne. Essas opções são transmitidas para o javac depois das opções globais.
`neverlink`	Booleano; o padrão é `False` Indica se essa biblioteca só deve ser usada para compilação e não no ambiente de execução. Útil se a biblioteca for fornecida pelo ambiente de execução durante a execução. Exemplos dessas bibliotecas são as APIs do ambiente de desenvolvimento integrado para plug-ins do ambiente de desenvolvimento integrado ou `tools.jar` para qualquer coisa executada em um JDK padrão. Observe que `neverlink = True` não impede que o compilador faça inlining de material dessa biblioteca em destinos de compilação que dependem dela, conforme permitido pela especificação da linguagem Java (por exemplo, constantes `static final` de `String` ou de tipos primitivos). Portanto, o caso de uso preferido é quando a biblioteca de tempo de execução é idêntica à biblioteca de compilação. Se a biblioteca de tempo de execução for diferente da biblioteca de compilação, verifique se ela difere apenas em locais em que a JLS proíbe os compiladores de inlining (e isso precisa ser válido para todas as versões futuras da JLS).
`plugins`	Lista de rótulos. O padrão é `[]`. Plug-ins do compilador Java para serem executados no tempo de compilação. Cada `java_plugin` especificado nesse atributo será executado sempre que a regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`proguard_specs`	Lista de rótulos. O padrão é `[]`. Arquivos a serem usados como especificação do Proguard. Eles descrevem o conjunto de especificações a serem usadas pelo ProGuard. Se especificados, eles serão adicionados a qualquer destino `android_binary` que dependa dessa biblioteca. Os arquivos incluídos aqui precisam ter apenas regras idempotentes, ou seja, -dontnote, -dontwarn, assumenosideeffects e regras que começam com -keep. Outras opções só podem aparecer em proguard_specs do `android_binary` para garantir fusões não tautológicas.
`resource_strip_prefix`	String; o padrão é `""` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho será removido de todos os arquivos no atributo `resources`. É um erro se um arquivo de recursos não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java dos arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.
`runtime_deps`	Lista de rótulos. O padrão é `[]`. Bibliotecas a serem disponibilizadas apenas para o binário final ou para teste no momento da execução. Assim como os `deps` comuns, eles aparecem no caminho de classe de execução, mas não no caminho de classe de compilação. As dependências necessárias apenas no tempo de execução devem ser listadas aqui. As ferramentas de análise de dependências precisam ignorar destinos que aparecem em `runtime_deps` e `deps`.

java_test

Ver origem da regra

java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, package_metadata, plugins, 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 em Java. Um teste é um wrapper binário ao redor do código de teste. O método principal do executor de testes é invocado em vez da classe principal ser compilada.

Metas de saída implícitas

name.jar: um arquivo Java.
name_deploy.jar: um arquivo Java adequado para implantação. (Criado somente se solicitado explicitamente.) Consulte a descrição da saída name_deploy.jar de java_binary para mais detalhes.

Consulte a seção sobre argumentos java_binary(). Essa regra também é compatível com 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`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos. O padrão é `[]`. A lista de outras bibliotecas a serem vinculadas ao destino. Consulte comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build.
`srcs`	Lista de rótulos. O padrão é `[]`. A lista de arquivos de origem processados para criar o destino. Esse atributo é quase sempre obrigatório. Confira as exceções abaixo. Os arquivos de origem do tipo `.java` são compilados. No caso de arquivos `.java` gerados, é recomendável colocar o nome da regra de geração aqui em vez do nome do arquivo em si. Isso não apenas melhora a legibilidade, mas também torna a regra mais resiliente a mudanças futuras: se a regra de geração gerar arquivos diferentes no futuro, basta corrigir um lugar: o `outs` da regra de geração. Não liste a regra de geração em `deps` porque ela não faz nada. Os arquivos de origem do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos `.java` com uma genrule. Regras: se a regra (normalmente `genrule` ou `filegroup`) gerar qualquer um dos arquivos listados acima, eles serão usados da mesma forma que os arquivos de origem. Esse argumento é quase sempre obrigatório, exceto se um atributo `main_class` especificar uma classe no classpath de tempo de execução ou se você especificar o argumento `runtime_deps`.
`data`	Lista de rótulos. O padrão é `[]`. A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte comentários gerais sobre `data` em Atributos típicos definidos pela maioria das regras de build.
`resources`	Lista de rótulos. O padrão é `[]`. Uma lista de arquivos de dados a serem incluídos em um jar Java. Os recursos podem ser arquivos de origem ou gerados. Se os recursos forem especificados, eles serão agrupados no jar junto com os arquivos `.class` comuns produzidos pela compilação. O local dos recursos dentro do arquivo jar é determinado pela estrutura do projeto. Primeiro, o Bazel procura o layout de diretório padrão (um diretório "src" seguido por um neto "resources"). Se não for encontrado, o Bazel vai procurar o diretório mais alto chamado "java" ou "javatests". Por exemplo, se um recurso estiver em `<workspace root>/x/java/y/java/z`, o caminho dele será `y/java/z`. Essa heurística não pode ser substituída. No entanto, o atributo `resource_strip_prefix` pode ser usado para especificar um diretório alternativo específico para arquivos de recursos.
`add_exports`	Lista de strings. O padrão é `[]`. Permite que a biblioteca acesse o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-exports=.
`add_opens`	Lista de strings. O padrão é `[]`. Permite que essa biblioteca acesse de forma reflexiva o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-opens=.
`bootclasspath`	Rótulo; o padrão é `None` API restrita, não use!
`classpath_resources`	Lista de rótulos. O padrão é `[]`. NÃO USE ESTA OPÇÃO A MENOS QUE NÃO HAJA OUTRA FORMA Uma lista de recursos que precisam estar na raiz da árvore Java. O único propósito desse atributo é oferecer suporte a bibliotecas de terceiros que exigem que os recursos sejam encontrados no classpath exatamente como `"myconfig.xml"`. Ele só é permitido em binários e não em bibliotecas, devido ao risco de conflitos de namespace.
`create_executable`	Booleano; o padrão é `True` obsoleto: use `java_single_jar`.
`deploy_manifest_lines`	Lista de strings. O padrão é `[]`. Uma lista de linhas a serem adicionadas ao arquivo `META-INF/manifest.mf` gerado para a meta `_deploy.jar`. O conteúdo desse atributo não* está sujeito à substituição de "Criar variável".
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para este binário. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne. Essas opções são transmitidas para o javac depois das opções globais.
`jvm_flags`	Lista de strings. O padrão é `[]`. Uma lista de flags a serem incorporadas no script de wrapper gerado para executar este binário. Sujeito à substituição de $(location) e "Criar variável" e à tokenização do shell Bourne. 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 wrapper inclui o nome da classe principal seguido por um `"$@"` para que você possa transmitir outros argumentos após o nome da classe. No entanto, os argumentos destinados à análise pela JVM precisam ser especificados antes do nome da classe na linha de comando. O conteúdo de `jvm_flags` é adicionado ao script wrapper antes da listagem do nome da classe. Esse atributo não tem efeito nas saídas de `*_deploy.jar`.
`launcher`	Rótulo; o padrão é `None` Especifique um binário que será usado para executar seu programa Java em vez do programa `bin/java` normal incluído no JDK. O destino precisa ser um `cc_binary`. Qualquer `cc_binary` que implemente a API Java Invocation pode ser especificado como um valor para esse atributo. Por padrão, o Bazel usa o inicializador normal do JDK (bin/java ou java.exe). A flag `--java_launcher` relacionada do Bazel afeta apenas os destinos `java_binary` e `java_test` que não especificaram um atributo `launcher`. As dependências nativas (C++, SWIG, JNI) são criadas de maneira diferente dependendo se você está usando o iniciador do JDK ou outro: Se você estiver usando o iniciador normal do JDK (o padrão), as dependências nativas serão criadas como uma biblioteca compartilhada chamada `{name}_nativedeps.so`, em que `{name}` é o atributo `name` dessa regra java_binary. O código não usado não é removido pelo vinculador nessa configuração. Se você estiver usando outro iniciador, as dependências nativas (C++) serão vinculadas estaticamente a um binário chamado `{name}_nativedeps`, em que `{name}` é o atributo `name` dessa regra java_binary. Nesse caso, o vinculador remove do binário resultante qualquer código que considere não utilizado. Isso significa que qualquer código C++ acessado apenas via JNI não será vinculado, a menos que o destino `cc_library` especifique `alwayslink = True`. Ao usar um iniciador diferente do padrão do JDK, o formato da saída `*_deploy.jar` muda. Consulte a documentação principal de java_binary para mais detalhes.
`main_class`	String; o padrão é `""` Nome da classe com o método `main()` a ser usado como ponto de entrada. Se uma regra usar essa opção, ela não precisará de uma lista `srcs=[...]`. Assim, com esse atributo, é possível criar um executável 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 estar disponível no tempo de execução: ela pode ser compilada por essa regra (de `srcs`) ou fornecida por dependências diretas ou transitivas (por `runtime_deps` ou `deps`). Se a classe não estiver disponível, o binário vai falhar no tempo de execução. Não há verificação no tempo de build.
`neverlink`	Booleano; o padrão é `False`
`plugins`	Lista de rótulos. O padrão é `[]`. Plug-ins do compilador Java para serem executados no tempo de compilação. Cada `java_plugin` especificado nesse atributo será executado sempre que a regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`resource_strip_prefix`	String; o padrão é `""` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho será removido de todos os arquivos no atributo `resources`. É um erro se um arquivo de recursos não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java dos arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.
`runtime_deps`	Lista de rótulos. O padrão é `[]`. Bibliotecas a serem disponibilizadas apenas para o binário final ou para teste no momento da execução. Assim como os `deps` comuns, eles aparecem no caminho de classe de execução, mas não no caminho de classe de compilação. As dependências necessárias apenas no tempo de execução devem ser listadas aqui. As ferramentas de análise de dependências precisam ignorar destinos que aparecem em `runtime_deps` e `deps`.
`stamp`	Número inteiro. O padrão é `0`. Determina se as informações de build serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre adicione as informações de build ao binário, mesmo em builds `--nostamp`. Evite essa configuração, já que ela pode encerrar o armazenamento em cache remoto para o binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitua as informações de build por valores constantes. Isso oferece um bom cache de resultados de build. `stamp = -1`: o embedding de informações de build é controlado pela flag `--[no]stamp`. Os binários carimbados não são recriados, a menos que as dependências mudem.
`test_class`	String; o padrão é `""` A classe Java a ser carregada pelo executor de testes. Por padrão, se esse argumento não for definido, o modo legado será usado, e os argumentos de teste serão usados. Defina a flag `--nolegacy_bazel_java_test` para não usar o primeiro argumento como substituto. Esse atributo especifica o nome de uma classe Java a ser executada por esse teste. É raro precisar definir isso. Se esse argumento for omitido, ele será inferido usando o `name` do destino e o caminho relativo à raiz de origem. Se o teste estiver fora de uma raiz de origem conhecida, o Bazel vai informar um erro se `test_class` não estiver definido. Para o JUnit3, a classe de teste precisa ser uma subclasse de `junit.framework.TestCase` ou ter um método `suite()` estático público que retorne um `junit.framework.Test` (ou uma subclasse de `Test`). Esse atributo permite que várias regras `java_test` compartilhem o mesmo `Test` (`TestCase`, `TestSuite` etc.). Normalmente, informações adicionais são transmitidas a ele (por exemplo, via `jvm_flags=['-Dkey=value']`) para que o comportamento seja diferente em cada caso, como executar um subconjunto diferente de testes. Esse atributo também permite o uso de testes Java fora da árvore `javatests`.
`use_launcher`	Booleano; o padrão é `True` Indica se o binário deve usar um iniciador personalizado. Se esse atributo for definido como "false", o atributo launcher e a flag `--java_launcher` relacionada serão ignorados para essa meta.
`use_testrunner`	Booleano; o padrão é `True` Use a classe do executor de testes (por padrão, `com.google.testing.junit.runner.BazelTestRunner`) como o ponto de entrada principal de um programa Java e forneça a classe de teste ao executor como um valor da propriedade do sistema `bazel.test_suite`. É possível usar isso para substituir o comportamento padrão, que é usar o executor de testes para regras `java_test`, e não usá-lo para regras `java_binary`. É improvável que você queira fazer isso. Um uso é para regras `AllTest` invocadas por outra regra (para configurar um banco de dados antes de executar os testes, por exemplo). A regra `AllTest` precisa ser declarada como um `java_binary`, mas ainda usa o executor de testes como ponto de entrada principal. O nome de uma classe de executor de teste pode ser substituído com o atributo `main_class`.

java_package_configuration

Ver origem da regra

java_package_configuration(name, data, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, javacopts, output_licenses, package_metadata, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)

Configuração a ser aplicada a um conjunto de pacotes. As configurações podem ser adicionadas a java_toolchain.javacoptss.

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`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`data`	Lista de rótulos. O padrão é `[]`. A lista de arquivos necessários para essa configuração no ambiente de execução.
`javacopts`	Lista de strings. O padrão é `[]`. Flags do compilador Java.
`output_licenses`	Lista de strings. O padrão é `[]`.
`packages`	Lista de rótulos. O padrão é `[]`. O conjunto de `package_group`s a que a configuração deve ser aplicada.
`system`	Rótulo; o padrão é `None` Corresponde à flag --system do javac.

java_plugin

Ver origem da regra

java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, package_metadata, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

O java_plugin define plug-ins para o compilador Java executado pelo Bazel. O único tipo de plug-ins compatível são os processadores de anotações. Uma regra java_library ou java_binary pode executar plug-ins dependendo deles pelo atributo plugins (link em inglês). Um java_library também pode exportar automaticamente plug-ins para bibliotecas que dependem diretamente dele usando exported_plugins.

Metas de saída implícitas

libname.jar: um arquivo Java.

Os argumentos são um subconjunto (e têm semântica idêntica) dos de java_library(), exceto pela adição dos argumentos processor_class e generates_api.

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos. O padrão é `[]`. A lista de bibliotecas a serem vinculadas a esta biblioteca. Consulte comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Os jars criados pelas regras `java_library` listadas em `deps` estarão no classpath de tempo de compilação dessa regra. Além disso, o fechamento transitivo de `deps`, `runtime_deps` e `exports` estará no classpath de tempo de execução. Por outro lado, os destinos no atributo `data` são incluídos nos runfiles, mas não no classpath de tempo de compilação nem de execução.
`srcs`	Lista de rótulos. O padrão é `[]`. A lista de arquivos de origem processados para criar o destino. Esse atributo é quase sempre obrigatório. Confira as exceções abaixo. Os arquivos de origem do tipo `.java` são compilados. No caso de arquivos `.java` gerados, é recomendável colocar o nome da regra de geração aqui em vez do nome do arquivo em si. Isso não apenas melhora a legibilidade, mas também torna a regra mais resiliente a mudanças futuras: se a regra de geração gerar arquivos diferentes no futuro, basta corrigir um lugar: o `outs` da regra de geração. Não liste a regra de geração em `deps` porque ela não faz nada. Os arquivos de origem do tipo `.srcjar` são descompactados e compilados. Isso é útil se você precisar gerar um conjunto de arquivos `.java` com uma genrule. Regras: se a regra (normalmente `genrule` ou `filegroup`) gerar qualquer um dos arquivos listados acima, eles serão usados da mesma forma que os arquivos de origem. Os arquivos de origem do tipo `.properties` são tratados como recursos. Todos os outros arquivos serão ignorados, desde que haja pelo menos um arquivo de um tipo descrito acima. Caso contrário, um erro será gerado. Esse argumento é quase sempre obrigatório, exceto se você especificar o argumento `runtime_deps`.
`data`	Lista de rótulos. O padrão é `[]`. A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte comentários gerais sobre `data` em Atributos típicos definidos pela maioria das regras de build. Ao criar um `java_library`, o Bazel não coloca esses arquivos em nenhum lugar. Se os arquivos `data` forem gerados, o Bazel os gera. Ao criar um teste que depende desse `java_library`, o Bazel copia ou vincula os arquivos `data` à área de arquivos de execução.
`resources`	Lista de rótulos. O padrão é `[]`. Uma lista de arquivos de dados a serem incluídos em um jar Java. Os recursos podem ser arquivos de origem ou gerados. Se os recursos forem especificados, eles serão agrupados no jar junto com os arquivos `.class` comuns produzidos pela compilação. O local dos recursos dentro do arquivo jar é determinado pela estrutura do projeto. Primeiro, o Bazel procura o layout de diretório padrão (um diretório "src" seguido por um neto "resources"). Se não for encontrado, o Bazel vai procurar o diretório mais alto chamado "java" ou "javatests". Por exemplo, se um recurso estiver em `<workspace root>/x/java/y/java/z`, o caminho dele será `y/java/z`. Essa heurística não pode ser substituída. No entanto, o atributo `resource_strip_prefix` pode ser usado para especificar um diretório alternativo específico para arquivos de recursos.
`add_exports`	Lista de strings. O padrão é `[]`. Permite que a biblioteca acesse o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-exports=.
`add_opens`	Lista de strings. O padrão é `[]`. Permite que essa biblioteca acesse de forma reflexiva o `module` ou `package` especificado. Isso corresponde às flags javac e JVM --add-opens=.
`bootclasspath`	Rótulo; o padrão é `None` API restrita, não use!
`generates_api`	Booleano; o padrão é `False` Esse atributo marca processadores de anotações que geram código de API. Se uma regra usar um processador de anotações que gera APIs, outras regras que dependem dela só poderão se referir ao código gerado se as ações de compilação forem programadas depois da regra de geração. Esse atributo instrui o Bazel a introduzir restrições de programação quando --java_header_compilation está ativado. AVISO: esse atributo afeta o desempenho do build. Use-o apenas se necessário.
`javabuilder_jvm_flags`	Lista de strings. O padrão é `[]`. API restrita, não use!
`javacopts`	Lista de strings. O padrão é `[]`. Opções extras do compilador para esta biblioteca. Sujeito à substituição de "Criar variável" e à tokenização do shell Bourne. Essas opções são transmitidas para o javac depois das opções globais.
`neverlink`	Booleano; o padrão é `False` Indica se essa biblioteca só deve ser usada para compilação e não no ambiente de execução. Útil se a biblioteca for fornecida pelo ambiente de execução durante a execução. Exemplos dessas bibliotecas são as APIs do ambiente de desenvolvimento integrado para plug-ins do ambiente de desenvolvimento integrado ou `tools.jar` para qualquer coisa executada em um JDK padrão. Observe que `neverlink = True` não impede que o compilador faça inlining de material dessa biblioteca em destinos de compilação que dependem dela, conforme permitido pela especificação da linguagem Java (por exemplo, constantes `static final` de `String` ou de tipos primitivos). Portanto, o caso de uso preferido é quando a biblioteca de tempo de execução é idêntica à biblioteca de compilação. Se a biblioteca de tempo de execução for diferente da biblioteca de compilação, verifique se ela difere apenas em locais em que a JLS proíbe os compiladores de inlining (e isso precisa ser válido para todas as versões futuras da JLS).
`output_licenses`	Lista de strings. O padrão é `[]`.
`plugins`	Lista de rótulos. O padrão é `[]`. Plug-ins do compilador Java para serem executados no tempo de compilação. Cada `java_plugin` especificado nesse atributo será executado sempre que a regra for criada. Uma biblioteca também pode herdar plug-ins de dependências que usam `exported_plugins`. Os recursos gerados pelo plug-in serão incluídos no jar resultante dessa regra.
`processor_class`	String; o padrão é `""` A classe do processador é o tipo totalmente qualificado da classe que o compilador Java deve usar como ponto de entrada para o processador de anotações. Se não for especificado, essa regra não vai contribuir com um processador de anotações para o processamento de anotações do compilador Java, mas o caminho de classe de tempo de execução ainda será incluído no caminho do processador de anotações do compilador. Isso é destinado principalmente ao uso por plug-ins do Error Prone, que são carregados do caminho do processador de anotações usando java.util.ServiceLoader.
`proguard_specs`	Lista de rótulos. O padrão é `[]`. Arquivos a serem usados como especificação do Proguard. Eles descrevem o conjunto de especificações a serem usadas pelo ProGuard. Se especificados, eles serão adicionados a qualquer destino `android_binary` que dependa dessa biblioteca. Os arquivos incluídos aqui precisam ter apenas regras idempotentes, ou seja, -dontnote, -dontwarn, assumenosideeffects e regras que começam com -keep. Outras opções só podem aparecer em proguard_specs do `android_binary` para garantir fusões não tautológicas.
`resource_strip_prefix`	String; o padrão é `""` O prefixo do caminho a ser removido dos recursos Java. Se especificado, esse prefixo de caminho será removido de todos os arquivos no atributo `resources`. É um erro se um arquivo de recursos não estiver nesse diretório. Se não for especificado (o padrão), o caminho do arquivo de recurso será determinado de acordo com a mesma lógica do pacote Java dos arquivos de origem. Por exemplo, um arquivo de origem em `stuff/java/foo/bar/a.txt` será localizado em `foo/bar/a.txt`.

java_runtime

Ver origem da regra

java_runtime(name, srcs, compatible_with, default_cds, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)

Especifica a configuração de 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`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`srcs`	Lista de rótulos. O padrão é `[]`. Todos os arquivos no tempo de execução.
`default_cds`	Rótulo; o padrão é `None` Arquivo CDS padrão para `java_runtime` hermético. Quando o modo hermético está ativado para um destino `java_binary`, o CDS padrão `java_runtime` é empacotado no JAR de implantação hermética.
`hermetic_srcs`	Lista de rótulos. O padrão é `[]`. Arquivos no ambiente de execução necessários para implantações herméticas.
`hermetic_static_libs`	Lista de rótulos. O padrão é `[]`. As bibliotecas vinculadas estaticamente ao inicializador para implantações herméticas.
`java`	Rótulo; o padrão é `None` O caminho para o executável Java.
`java_home`	String; o padrão é `""` O caminho para a raiz do ambiente de execução. Sujeito à substituição da variável "Make". Se esse caminho for absoluto, a regra vai indicar um ambiente de execução Java não hermético com um caminho conhecido. Nesse caso, os atributos `srcs` e `java` precisam estar vazios.
`lib_ct_sym`	Rótulo; o padrão é `None` O arquivo lib/ct.sym necessário para a compilação com `--release`. Se não for especificado e houver exatamente um arquivo em `srcs` cujo caminho termine com `/lib/ct.sym`, esse arquivo será usado.
`lib_modules`	Rótulo; o padrão é `None` O arquivo lib/modules necessário para implantações herméticas.
`output_licenses`	Lista de strings. O padrão é `[]`.
`version`	Número inteiro. O padrão é `0`. A versão do recurso do ambiente de execução do Java. Ou seja, o número inteiro retornado por `Runtime.version().feature()`.

java_single_jar

Ver origem da regra

java_single_jar(name, deps, compatible_with, compress, deploy_env, deploy_manifest_lines, deprecation, exclude_build_data, exec_compatible_with, exec_group_compatible_with, exec_properties, features, multi_release, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Coleta dependências Java e arquivos jar em um único jar `java_single_jar` coleta dependências Java e arquivos jar em um único jar. Isso é semelhante ao java_binary com tudo relacionado a executáveis desativado, e oferece uma alternativa ao "hack de implantação de jar" do java_binary. ## Exemplo ```skylark load("//tools/build_defs/java_single_jar:java_single_jar.bzl", "java_single_jar") java_single_jar( name = "my_single_jar", deps = [ "//java/com/google/foo", "//java/com/google/bar", ], ) ``` Saídas: {name}.jar: um único arquivo JAR que contém todas as entradas.

Argumentos

Atributos
`name`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`deps`	Lista de rótulos. O padrão é `[]`. Os destinos Java (incluindo java_import e java_library) de onde coletar dependências transitivas. As dependências de tempo de execução são coletadas por deps, exports e runtime_deps. Os recursos também são coletados. Dependências nativas de cc_library ou java_wrap_cc não são.
`compress`	String; o padrão é `"preserve"` Se deve sempre usar o algoritmo deflate ("yes"), sempre armazenar ("no") ou transmitir sem modificações ("preserve"). O padrão é "preservar", que é a opção mais eficiente. Nenhum trabalho extra é feito para inflar ou reduzir.
`deploy_env`	Lista de rótulos. O padrão é `[]`. Uma lista de destinos "java_binary" ou "java_single_jar" que representam o ambiente de implantação desse binário. Defina esse atributo ao criar um plug-in que será carregado por outro `java_binary`. As dependências de `deploy_env` são excluídas do jar criado por essa regra.
`deploy_manifest_lines`	Lista de strings. O padrão é `[]`. Uma lista de linhas a serem adicionadas ao arquivo `META-INF/manifest.mf`.
`exclude_build_data`	Booleano; o padrão é `True` Define se o arquivo build-data.properties gerado por padrão deve ser omitido.
`multi_release`	Booleano; o padrão é `True` Define se os jars de saída de várias versões serão ativados.

java_toolchain

Ver origem da regra

java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, exec_compatible_with, exec_group_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, package_metadata, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)

Especifica a configuração do compilador Java. A cadeia de ferramentas a ser usada pode ser alterada com o argumento --java_toolchain. 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`	Nome: obrigatório Um nome exclusivo para essa segmentação.
`android_lint_data`	Lista de rótulos. O padrão é `[]`. Rótulos de ferramentas disponíveis para expansão de rótulos em android_lint_jvm_opts.
`android_lint_jvm_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos da JVM ao invocar o Android Lint.
`android_lint_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos do Android Lint.
`android_lint_package_configuration`	Lista de rótulos. O padrão é `[]`. Configuração do Android Lint que deve ser aplicada aos grupos de pacotes especificados.
`android_lint_runner`	Rótulo; o padrão é `None` Rótulo do executor do Android Lint, se houver.
`bootclasspath`	Lista de rótulos. O padrão é `[]`. As entradas de bootclasspath de destino do Java. Corresponde à flag -bootclasspath do javac.
`compatible_javacopts`	nulo; o padrão é `{}` API interna, não use.
`deps_checker`	Rótulo; o padrão é `None` Rótulo do jar de implantação do ImportDepsChecker.
`forcibly_disable_header_compilation`	Booleano; o padrão é `False` Substitui --java_header_compilation para desativar a compilação de cabeçalho em plataformas que não a oferecem suporte, como o JDK 7 Bazel.
`genclass`	Rótulo; o padrão é `None` Rótulo do jar de implantação do GenClass.
`header_compiler`	Rótulo; o padrão é `None` Rótulo do compilador de cabeçalho. Obrigatório se a flag "--java_header_compilation" estiver ativada.
`header_compiler_builtin_processors`	Lista de strings. O padrão é `[]`. API interna, não use.
`header_compiler_direct`	Rótulo; o padrão é `None` Rótulo opcional do compilador de cabeçalho a ser usado para ações diretas de classpath que não incluem processadores de anotação geradores de API. Essa ferramenta não é compatível com o processamento de anotações.
`ijar`	Rótulo; o padrão é `None` Rótulo do executável ijar.
`jacocorunner`	Rótulo; o padrão é `None` Rótulo do jar de implantação do JacocoCoverageRunner.
`java_runtime`	Rótulo; o padrão é `None` O java_runtime a ser usado com esse conjunto de ferramentas. O padrão é java_runtime na configuração de execução.
`javabuilder`	Rótulo; o padrão é `None` Rótulo do jar de implantação do JavaBuilder.
`javabuilder_data`	Lista de rótulos. O padrão é `[]`. Rótulos de dados disponíveis para expansão de rótulos em javabuilder_jvm_opts.
`javabuilder_jvm_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos para a JVM ao invocar o JavaBuilder.
`javac_supports_multiplex_workers`	Booleano; o padrão é `True` Verdadeiro se o JavaBuilder for compatível com a execução como um worker persistente de multiplexação. Caso contrário, será falso.
`javac_supports_worker_cancellation`	Booleano; o padrão é `True` Verdadeiro se o JavaBuilder oferecer suporte ao cancelamento de workers persistentes, falso se não oferecer.
`javac_supports_worker_multiplex_sandboxing`	Booleano; o padrão é `False` Verdadeiro se o JavaBuilder aceitar a execução como um worker persistente multiplexado com sandbox, falso se não aceitar.
`javac_supports_workers`	Booleano; o padrão é `True` Verdadeiro se o JavaBuilder for compatível com a execução como um worker persistente, falso se não for.
`javacopts`	Lista de strings. O padrão é `[]`. A lista de argumentos extras para o compilador Java. Consulte a documentação do compilador Java para ver a lista completa de flags possíveis.
`jspecify_implicit_deps`	Rótulo; o padrão é `None` Experimental, não use!
`jspecify_javacopts`	Lista de strings. O padrão é `[]`. Experimental, não use!
`jspecify_packages`	Lista de rótulos. O padrão é `[]`. Experimental, não use!
`jspecify_processor`	Rótulo; o padrão é `None` Experimental, não use!
`jspecify_processor_class`	String; o padrão é `""` Experimental, não use!
`jspecify_stubs`	Lista de rótulos. O padrão é `[]`. Experimental, não use!
`jvm_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos da JVM ao invocar o compilador Java. Consulte a documentação da máquina virtual Java para ver a lista completa de flags possíveis para essa opção.
`misc`	Lista de strings. O padrão é `[]`. Descontinuado: use javacopts
`oneversion`	Rótulo; o padrão é `None` Rótulo do binário de aplicação de uma versão.
`oneversion_allowlist`	Rótulo; o padrão é `None` Rótulo da lista de permissões de uma versão.
`oneversion_allowlist_for_tests`	Rótulo; o padrão é `None` Rótulo da lista de permissões de uma versão para testes.
`oneversion_whitelist`	Rótulo; o padrão é `None` Descontinuado: use oneversion_allowlist
`package_configuration`	Lista de rótulos. O padrão é `[]`. Configuração que deve ser aplicada aos grupos de pacotes especificados.
`proguard_allowlister`	Rótulo; o padrão é `"@bazel_tools//tools/jdk:proguard_whitelister"` Rótulo da lista de permissões do Proguard.
`reduced_classpath_incompatible_processors`	Lista de strings. O padrão é `[]`. API interna, não use.
`singlejar`	Rótulo; o padrão é `None` Rótulo do jar de implantação SingleJar.
`source_version`	String; o padrão é `""` A versão de origem do Java (por exemplo, "6" ou "7"). Ele especifica qual conjunto de estruturas de código é permitido no código-fonte Java.
`target_version`	String; o padrão é `""` A versão de destino do Java (por exemplo, "6" ou "7"). Ele especifica para qual ambiente de execução do Java a classe deve ser criada.
`timezone_data`	Rótulo; o padrão é `None` Rótulo de um jar de recursos que contém dados de fuso horário. Se definido, os dados de fuso horário serão adicionados como uma dependência de tempo de execução implícita de todas as regras java_binary.
`tools`	Lista de rótulos. O padrão é `[]`. Rótulos de ferramentas disponíveis para expansão de rótulos em jvm_opts.
`turbine_data`	Lista de rótulos. O padrão é `[]`. Rótulos de dados disponíveis para expansão de rótulos em turbine_jvm_opts.
`turbine_jvm_opts`	Lista de strings. O padrão é `[]`. A lista de argumentos para a JVM ao invocar o Turbine.
`xlint`	Lista de strings. O padrão é `[]`. A lista de avisos a serem adicionados ou removidos da lista padrão. Preceda com um traço para remover. Consulte a documentação do Javac sobre as opções -Xlint para mais informações.