gradle multi project example
1.0.0
O stub genérico único/multi-projeto que achamos que representa o melhor que o gradle tem a oferecer.
| Nome | Questões | CI | Codecov | Documentos | Liberar |
|---|---|---|---|---|---|
| UTILOS COMUMOS |
Pode ser proveniente de artefactory/bintray como assim:
<dependency>
<groupId>com.aries</groupId>
<artifactId>project-name</artifactId>
<version>X.Y.Z</version>
<classifier>sources|tests|docs|all</classifier> (Optional)
</dependency>
Para projetos independentes, você pode criar o diretório típico src/main/<language> na raiz deste projeto e as coisas funcionarão conforme o esperado. Neste modelo, não há problema em remover o diretório projects depois de ter as coisas no lugar.
Para vários projetos, você precisa criar/colocar os referidos projetos no diretório projects . A colocação do (s) projeto (s) aqui os criará automaticamente como parte dessa compilação com vários projetos.
Para ambos os casos, você pode precisar girar um pouco os botões no arquivo gradle/projects.gradle dependendo do tipo de projeto que você deseja criar.
A estrutura do pacote do seu projeto deve começar com o seu group Gradle, seguido pelo nome do projeto. Como parte da construção do seu projeto, examinaremos suas fontes e garantiremos que esse padrão seja atendido. Por exemplo: se o seu grupo for com.github.gradle e você estará adicionando um projeto chamado calamari , a estrutura do pacote desse projeto deve parecer com/github/gradle/calamari .
Se você estiver adicionando um projeto cujo nome contém caracteres não alfabéticos, esses caracteres serão convertidos em slashes para a frente ao executar a verificação mencionada anteriormente. Por exemplo: se o seu projeto for denominado tuna-casserole , a estrutura da sua embalagem ficaria com `com/github/gradle/atum/caçarola.
Jacoco : é uma ferramenta que garante que o novo código tenha cobertura de teste adequada.
ErrorProne : é uma ferramenta de análise estática para Java que captura erros de programação comuns em tempo de compilação e sugere correções.
Checkstyle : é uma ferramenta de desenvolvimento que força os programadores a escrever código que adere a um padrão comum.
PMD : é um analisador de código -fonte que encontra falhas de programação comuns, como variáveis não utilizadas, blocos de captura vazios, criação desnecessária de objetos e assim por diante.
FindBugs : é uma ferramenta que usa análise estática para procurar e detectar possíveis erros no código Java.
Atualmente, definimos junit e assertj como dependências testCompile para todos os projetos. Vamos tentar se concentrar em usar apenas isso e, se houver necessidade de atrair e usar outra coisa, então vamos primeiro discutir isso antes de adicionarmos n número de dependências a este projeto e quebrar a aparência que estamos tentando definir.
O código é considerado feito quando todas as verificações foram passadas, o código pode ser compilado e, no mínimo, os testes de integração e unidade foram adicionados para abordar o novo código.
