Maven vs Gradle em projetos Java: Qual escolher?

No ecossistema Java, ferramentas de build automation são fundamentais para compilar código, gerenciar dependências, executar testes e gerar artefatos como JAR ou WAR. As duas ferramentas mais utilizadas são Apache Maven e Gradle.

Ambas resolvem o mesmo problema, automatizar o ciclo de build de aplicações Java, porém utilizam abordagens diferentes.

No presente artigo vamos analisar:

• O que são Maven e Gradle
• Como cada um funciona
• Prós e contras
• Quando usar cada ferramenta em projetos Java

O que é Maven?

Apache Maven é uma ferramenta de build criada pela Apache Software Foundation e lançada em 2004.

Seu principal objetivo é padronizar o processo de build em projetos Java.

Ele utiliza um arquivo chamado pom.xml (Project Object Model) onde são declarados:

• dependências
• plugins
• versão do projeto
• configuração de build
• repositórios

Exemplo do arquivo pom.xml para o projeto Spring Framework 7 com Java 21 + JUnit + cobertura mínima de 80%

pom.xml

O Maven segue o princípio Convention over Configuration, ou seja, ele já possui uma estrutura padrão:

src/main/java
src/main/resources
src/test/java
src/test/resources

Essa padronização facilita a colaboração entre equipes.

O que é Gradle?

Gradle surgiu em 2012 como uma alternativa mais flexível e performática ao Maven.

Ele utiliza uma DSL baseada em Groovy ou Kotlin para definir o build.

Exemplo de arquivo build.gradle para o projeto Spring Framework 7 e Java 21 + JUnit + cobertura mínima de 80%:

build.gradle

O Gradle foi projetado para:

• builds mais rápidos
• maior flexibilidade
• melhor suporte a projetos complexos

Hoje ele é amplamente usado em projetos modernos, incluindo o build padrão do Android Studio.

Diferenças conceituais

Característica	Maven	Gradle
Configuração	XML (pom.xml)	DSL baseada em Groovy ou Kotlin
Filosofia	Convention over Configuration	Alta flexibilidade e customização
Performance	Mais lento em builds grandes	Mais rápido com incremental build e cache
Curva de aprendizado	Mais simples para iniciantes	Maior devido à DSL programável
Customização	Limitada via plugins	Muito alta, com scripts programáveis

Prós do Maven

1. Padronização

O Maven impõe uma estrutura padrão para projetos.

Isso facilita:

onboarding de novos desenvolvedores

manutenção de projetos

integração entre equipes

2. Ecossistema maduro

O Maven possui milhares de plugins prontos.

Exemplos:

compilação

geração de documentação

análise de código

empacotamento

3. Simplicidade conceitual

Apesar do XML ser verboso, o modelo é simples:

clean
compile
test
package
install
deploy

Esse ciclo é chamado de build lifecycle.

4. Alta adoção corporativa

Muitas empresas utilizam Maven em aplicações enterprise, especialmente em projetos baseados em:

• Spring Framework
• Spring Boot
• aplicações legadas Java

Contras do Maven

1. XML verboso

Configurações simples podem virar arquivos grandes.

Exemplo comum: pom.xml com centenas de linhas.

2. Customização limitada

Criar pipelines complexos pode ser difícil.

3. Performance menor

Comparado ao Gradle, o Maven:

• recompila mais coisas
• possui menos otimizações

Prós do Gradle

1. Build mais rápido

Gradle implementa várias otimizações:

• incremental build
• build cache
• execução paralela

Isso reduz bastante o tempo de build em projetos grandes.

2. DSL mais expressiva

A configuração é escrita em Groovy ou Kotlin, permitindo:

• lógica condicional
• loops
• funções
• scripts reutilizáveis
3. Melhor para projetos grandes

Gradle funciona muito bem com:

• monorepos
• microservices
• builds multi-módulo
4. Flexibilidade extrema

É possível construir praticamente qualquer pipeline de build.

Contras do Gradle

1. Curva de aprendizado maior

Desenvolvedores precisam entender:

• Groovy ou Kotlin
• conceitos de tasks
• lifecycle do Gradle
2. Menos padronização

Como tudo pode ser customizado, projetos podem ficar inconsistentes entre equipes.

3. Debug de build mais complexo

Scripts muito dinâmicos podem dificultar troubleshooting.

Maven vs Gradle em projetos reais

Na prática, a escolha depende do tipo de projeto.

Use Maven quando:

• o projeto é corporativo tradicional
• a equipe prefere padronização
• builds não são extremamente complexos
• onboarding rápido é importante

Use Gradle quando:

• o projeto é grande ou modular
• erformance de build é crítica
• pipelines precisam de customização
• o projeto envolve Android

Tendências do ecossistema Java

Nos últimos anos, Gradle tem crescido bastante, especialmente em projetos modernos.

Entretanto, Maven ainda domina grande parte do mercado corporativo devido à sua estabilidade e padronização.

Ou seja:

• Maven -> estabilidade e padrão
• Gradle -> flexibilidade e performance

Considerações finais

Tanto Apache Maven quanto Gradle são excelentes ferramentas de build para projetos Java.

A escolha correta depende de fatores como:

• complexidade do projeto
• tamanho da equipe
• necessidade de customização
• tempo de build

Em termos simples:

• Maven é previsível e padronizado
• Gradle é poderoso e flexível

Um engenheiro de software moderno deve conhecer ambos, pois cada um continua sendo amplamente utilizado nas empresas.

Feito!

Sincronizando seu projeto frontend (Angular) com testes unitários (Jest) no SonarQube

Em ambientes corporativos, a análise de qualidade de código e cobertura de testes é essencial para garantir a confiabilidade das aplicações. O SonarQube é uma das ferramentas mais usadas para isso, e pode ser facilmente integrado a projetos Angular com Jest.

No presente artigo, vamos ver o passo a passo para configurar essa integração, incluindo o uso do SonarQube em container Docker, a execução dos testes unitários e a geração de relatórios de cobertura.

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

1. Subindo o SonarQube com Docker

Primeiro, vamos utilizar a imagem oficial do SonarQube. Execute o comando abaixo:

docker run -d --name sonarqube-frontend -p 9000:9000 sonarqube:latest

O SonarQube estará acessível em http://localhost:9000.

No primeiro acesso, o login padrão é admin / admin.

Após logar, altere a senha e gere um token de autenticação no menu:

My Account → Security → Generate Tokens

Guarde esse token, pois ele será utilizado no arquivo de configuração do scanner.

2. Instalando o Jest e o Sonar Scanner

No seu projeto Angular, instale o Jest e o Sonar Scanner globalmente e localmente para garantir compatibilidade:

Instalar o sonar-scanner globalmente

npm install -g sonar-scanner

Instalar o sonar-scanner como dependência de desenvolvimento

npm install --save-dev sonar-scanner

Se o Jest ainda não estiver configurado no projeto Angular:

npm install --save-dev jest @types/jest jest-preset-angular

Em seguida, adicione o script de testes no package.json:

"scripts": {
  "test": "jest --silent",
  "test:coverage": "jest --coverage",
  "sonar": "sonar-scanner"
}

3. Configurando o arquivo sonar-project.properties

   Crie o arquivo sonar-project.properties na raiz do projeto Angular com o seguinte conteúdo:

   
   sonar.projectKey=Nome-Projeto-Frontend
   sonar.projectName=Nome-Projeto-Frontend
   sonar.projectVersion=1.0
   sonar.sources=src
   sonar.language=ts
   sonar.sourceEncoding=UTF-8
   sonar.host.url=http://localhost:9000
   sonar.login=TOKEN_AQUI
   sonar.branch.name=develop
   
   # Diretório de relatórios do Jest
   sonar.javascript.lcov.reportPaths=coverage/lcov.info
   
   

   O campo sonar.javascript.lcov.reportPaths é essencial para que o SonarQube consiga ler a cobertura de testes gerada pelo Jest.

4. Executando os testes e enviando o relatório

Antes de executar o SonarQube, é necessário garantir que os testes unitários estão passando e que o relatório de cobertura foi gerado corretamente.

Execute os testes normalmente:

npx jest --silent

Se todos os testes passarem, gere o relatório de cobertura:

Isso criará uma pasta coverage na raiz do projeto com o arquivo lcov.info dentro de coverage/lcov-report.

5. Enviando os resultados ao SonarQube

Com os testes e cobertura prontos, execute o comando abaixo:

npm run sonar

O sonar-scanner lerá as configurações do arquivo sonar-project.properties e enviará o relatório para o servidor do SonarQube.

Ao finalizar, acesse o painel do SonarQube e verifique as métricas do seu projeto, incluindo:

Qualidade do código TypeScript

Cobertura de testes Jest

Bugs, vulnerabilidades e code smells

Dica: executando no Git Bash (Windows)

Se você estiver no Windows, use o Git Bash para simular um ambiente Linux.

O comando sonar-scanner funciona normalmente nesse terminal, o que facilita a integração em ambientes de desenvolvimento heterogêneos.

Considerações finais

Integrar o Jest com o SonarQube é uma prática que eleva o nível de qualidade do seu projeto Angular.

Essa integração permite visualizar métricas detalhadas, acompanhar a evolução da cobertura de testes e identificar pontos críticos no código.

Com essa configuração, seu pipeline local ou CI/CD estará preparado para medir qualidade de forma contínua, garantindo um código mais limpo, seguro e sustentável.

Feito!

Entenda o conceito que está revolucionando o desenvolvimento de software

A área de tecnologia está em constante transformação, e um dos conceitos mais importantes da atualidade é o DevOps. Mais do que uma simples combinação entre "Desenvolvimento" e "Operações", o DevOps representa uma mudança cultural e técnica que tem ajudado empresas a entregar software de forma mais rápida, segura e eficiente.

No presente artigo, vamos explorar o que é DevOps, por que ele surgiu, quais são seus principais benefícios e como essa prática tem mudado a forma como times de tecnologia trabalham em conjunto.

Por que surgiu o DevOps?

Durante muito tempo, as áreas de desenvolvimento e infraestrutura (operações) trabalhavam de forma isolada. O time de desenvolvimento era responsável por escrever o código, enquanto o time de operações cuidava da infraestrutura e da publicação do sistema. Essa separação gerava atrasos, conflitos e até falhas em produção, principalmente quando havia mudanças frequentes.

Foi nesse contexto que surgiu o DevOps, como uma resposta à necessidade de melhorar a comunicação entre os times, automatizar processos e garantir entregas mais confiáveis. O termo começou a ganhar força por volta de 2009, a partir de comunidades de tecnologia que buscavam uma cultura mais colaborativa.

O que é DevOps, afinal?

DevOps é um conjunto de práticas, ferramentas e uma cultura organizacional que visa integrar os times de desenvolvimento (Dev) e operações (Ops), promovendo colaboração contínua ao longo de todo o ciclo de vida do software, desde o planejamento e desenvolvimento até a entrega e manutenção em produção.

O foco do DevOps é criar um ambiente onde as equipes possam trabalhar de forma conjunta, entregando valor de forma contínua, ágil e com qualidade.

Quais são os pilares do DevOps?

Para funcionar bem, o DevOps se apoia em alguns pilares fundamentais:

• Colaboração:

Times multidisciplinares que trabalham juntos com objetivos em comum.

• Automação:

Processos como testes, integração contínua, entrega contínua e monitoramento são automatizados.

• Integração Contínua (CI):

Cada alteração de código é integrada ao projeto automaticamente, garantindo testes e feedback rápidos.

• Entrega Contínua (CD):

Novas versões do sistema são entregues com frequência e com menos riscos.

• Monitoramento e feedback:

O sistema é monitorado em tempo real e os times utilizam os dados para melhorar continuamente.

Benefícios do DevOps

Adotar DevOps traz uma série de benefícios para empresas e profissionais de tecnologia. Entre os principais, destacam-se:

• Entregas mais rápidas e frequentes de software;
• Maior confiabilidade nas implantações em produção;
• Redução de erros e falhas;
• Melhoria na colaboração entre áreas;
• Maior satisfação do cliente.

Além disso, o DevOps permite uma melhor adaptação a mudanças, essencial em um mercado tão dinâmico como o de tecnologia.

DevOps é só ferramenta?

Embora existam muitas ferramentas que suportam práticas DevOps (como Jenkins, Docker, Kubernetes, GitLab CI/CD, entre outras), é importante entender que DevOps é, antes de tudo, uma mudança de cultura.

Sem colaboração entre os times e comprometimento com a melhoria contínua, nenhuma ferramenta será suficiente para garantir o sucesso da adoção de DevOps.

Considerações finais:

DevOps é uma abordagem que vem transformando a maneira como desenvolvemos e entregamos software. Ao unir desenvolvimento e operações com foco em automação, colaboração e melhoria contínua, as empresas conseguem ser mais ágeis, resilientes e inovadoras.

Se você trabalha com tecnologia, seja como desenvolvedor, administrador de sistemas, QA ou gestor, entender e aplicar os princípios de DevOps pode ser um diferencial importante na sua carreira e nos resultados da sua equipe.

Feito!

A Importância da cobertura de testes e da integração do SonarQube no ciclo de vida de um projeto

Em projetos de software, a busca por qualidade e confiabilidade deve ser constante. Muitas vezes, o time foca em entregar funcionalidades rapidamente, mas negligencia práticas essenciais que garantem a manutenção saudável do código a médio e longo prazo. Duas dessas práticas são: cobertura de testes automatizados e integração com ferramentas de análise estática como o SonarQube.

Por que se preocupar com cobertura de testes?

Testes automatizados, sejam unitários, de integração ou de ponta a ponta, têm um papel fundamental: garantir que o comportamento esperado da aplicação se mantenha ao longo do tempo. A cobertura de testes, por sua vez, é uma métrica que indica qual parte do código está sendo exercitada pelos testes.

Embora uma cobertura de 100% não signifique código 100% livre de bugs, uma baixa cobertura é um sinal de alerta. Código sem testes está mais propenso a falhas quando sofre alterações, principalmente em times grandes, onde o conhecimento sobre determinadas áreas do sistema nem sempre é compartilhado.

Benefícios diretos da cobertura de testes

• Redução de regressões: mudanças não quebram funcionalidades existentes.
• Facilidade de refatoração: refatorar com testes confiáveis é como ter uma rede de segurança.
• Documentação viva: bons testes explicam como o sistema deve se comportar.
• Mais confiança na entrega contínua: possibilita integração e deploy frequentes.

SonarQube: seu aliado na saúde do código

O SonarQube é uma ferramenta de análise estática que ajuda a monitorar a qualidade do código-fonte. Ele aponta bugs, code smells, vulnerabilidades e cobertura de testes. Quando integrado a um pipeline de CI/CD (Jenkins, GitHub Actions, GitLab CI, Azure DevOps), ele se torna um gate de qualidade.

Vantagens de integrar o projeto com o SonarQube:

• Visibilidade clara de pontos fracos no código.
• Monitoramento da cobertura de testes e da dívida técnica.
• Padronização de boas práticas e convenções de código.
• Alertas em tempo real de violações críticas de qualidade.
• Feedback imediato ao time durante pull requests.

Com o SonarQube, não se trata apenas de "escrever código que funciona", mas sim de escrever código limpo, seguro e sustentável.

Estratégia prática: como começar

1. Crie uma suíte mínima de testes automatizados: Comece testando as partes críticas da aplicação.
2. Adote TDD sempre que possível: Isso impulsiona a escrita de código testável.
3. Integre o SonarQube no seu pipeline (ex: Jenkins, GitHub Actions, GitLab CI).
4. Defina métricas mínimas aceitáveis de cobertura e qualidade (por exemplo, 40% de cobertura mínima e zero bugs críticos).

Promova uma cultura de qualidade: Revisões de código devem considerar a cobertura e o feedback do SonarQube.

Considerações finais

Desenvolver sem testes é como construir um prédio sem fundações. E seguir sem análise de qualidade contínua é não perceber as rachaduras que surgem no caminho. A integração de testes automatizados com o SonarQube traz uma cultura de qualidade que não só beneficia a equipe de desenvolvimento, mas toda a organização, entregando valor de forma contínua, sustentável e segura.

Testar é responsabilidade de todos os desenvolvedores e QAs. Monitorar a qualidade também.

Feito!

Instalando e Configurando o SonarQube no ambiente Docker

O objetivo deste post, é explicar os procedimentos de instalação e configuração do SonarQube no ambiente Docker.

O que é SonarQube?

SonarQube é um software open-source que se propõe a ser a central de qualidade do seu código-fonte, lhe possibilitando o controle sobre um grande número de métricas de software, e ainda apontando uma série de possíveis bugs.

Instalação e configuração

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

$ mkdir $HOME/sonarqube
$ cd $HOME/sonarqube

Executar no HOST antes

Para que o nó do Elastiscsearch seja inicializado com sucesso, pois o SonarQube utiliza o Elasticsearch na indexação nas buscas.

Para verificar a vm.max_map_count atual, execute o seguinte comando:

$ cat /proc/sys/vm/max_map_count

Se a contagem de mapas não for 262144, siga estas etapas:

1. Atualize o arquivo /etc/sysctl.conf com o seguinte valor: vm.max_map_count=262144

2. Execute o comando a seguir para aplicar as alterações sem reiniciar o nó.
$ sudo sysctl -q -w vm.max_map_count=262144

$ curl -sSL https://raw.githubusercontent.com/bitnami/bitnami-docker-sonarqube/master/docker-compose.yml > docker-compose.yml

PS: Para utilizar no servidor de produção, é recomendado alterar a variável ALLOW_EMPTY_PASSWORD de "yes" para "no" e definir um password seguro para o SGBD PostgreSQL utilizado no SonarQube e o usuário administrador de acesso ao SonarQube.

Adicionar as variáveis SONARQUBE_USERNAME e SONARQUBE_PASSWORD para um nome de usuário e password que irá gerenciar o SonarQube.

$ docker-compose up -d

Aguarde subir o ambiente, após concluir, abre o browser e acesse http://localhost

No primeiro acesso, o username/password default são: admin/bitnami. Caso tenha alterado o username/password default no arquivo docker-compose.yml, então utilize o que você definiu.

Após o acesso do SonarQube, pode inserir as métricas de análise do código para o seu projeto e integrar com o SonarLint na IDE que estiver utilizando no desenvolvimento do seu projeto, também no CI/CD (Continuos Integrations/Continuos Delivery).

O que é CI/CD?

CI/CD (Continuous Integration/Continuous Delivery), é um método para entregar aplicações com frequência aos clientes. Para isso, é aplicada a automação nas etapas do desenvolvimento de aplicações.

Exemplos de ferramentas que fazem CI/CD: Jenkins, Bamboo, GitHub Actions, CircleCI.

Utilize a ferramenta CI/CD a sua escolha para o seu projeto. É importante ressaltar que essas ferramentas de CI/CD integram com o Git com as plataformas GitHub, Bitbucket e Gitlab.

Feito!

Instalando e Configurando o SonarQube no Debian

O que é SonarQube ?

SonarQube é um software open-source que se propõe a ser a central de qualidade do seu código-fonte, lhe possibilitando o controle sobre um grande número de métricas de software, e ainda apontando uma série de possíveis bugs.

Depois de conhecer o SonarQube e pra que serve, podemos seguir os procedimentos de instalação e configuração do SonarQube em seu servidor GNU/Linux Debian.

Observação: Testado no GNU/Linux Debian 8 (Jessie) e versão atual do SonarQube é 5.1.2 até a data de publicação deste post.

Pré-requisitos: JDK, MySQL ou PostgreSQL.
Nesse post, será utilizado o Java 1.8, e MySQL

Download JDK
x86: wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u60-b27/jdk-8u60-linux-i586.tar.gz"
x64: wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u60-b27/jdk-8u60-linux-x64.tar.gz"

Download SonarQube
wget -c "https://sonarsource.bintray.com/Distribution/sonarqube/sonarqube-5.1.2.zip"

Instalação do MySQL
#apt-get update
#apt-get install mysql-server libmysqlclient15-dev

Configurando JDK
#apt-get purge openjdk-7-jre gcj-4.7-base gcj-4.7-jre openjdk-6-jre-headless #apt-get remove --purge openjdk-*

#mkdir /opt/java
#tar -xzvf jdk-8u60-linux-i586.tar.gz -C /opt/java

Criando link simbólico jdk8
#ln -s /opt/java/jdk1.8.0_6/ jdk8

Adicionar variável de ambiente $JAVA_HOME no PATH do sistema.
#vim /etc/profile
export JAVA_HOME="/opt/java/jdk8"
export CLASSPATH="$JAVA_HOME/lib":$CLASSPATH
export PATH="$JAVA_HOME/bin":$PATH
export MANPATH="$JAVA_HOME/man":$MANPATH

ESC +:x (para salvar e sair do editor Vim).
O mesmo conteúdo da variável de ambiente $JAVA_HOME no arquivo /etc/environment>
#source /etc/profile
#source /etc/environment

Criando o banco de dados Sonarqube no MySQL
# mysql_install_db
# mysql -u root -p
Enter password: < digite a senha de root que foi definida na instalação do MySQL >
mysql> create database sonar character set utf8;

Criar o usuário sonar para o banco sonar
mysql> GRANT ALL PRIVILEGES ON *.* TO sonar@localhost IDENTIFIED BY 'senha_sonar' WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)
mysql> quit

Configurando SonarQube
#unzip sonarqube-5.1.2.zip -d /opt
#cd /opt/sonarqube-5.1.2
#vim conf/sonar.properties
Por fim o username/password do banco de dados utilizado.
linha 18: sonar.jdbc.username: sonar
linha 19: sonar.jdbc.password: senha_sonarqube
Descomentar a linha referente ao banco de dados que será utilizado, nesse caso é o MySQL.
linha 33: sonar.jdbc.url: jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true
Definir o host/context
linha 99: sonar.web.host: Hostaname OU IP
linha 103: sonar.web.context: /sonar
Descomentar a linha 106 onde define a porta utilizada no Sonar.
linha 106: sonar.web.port=9000
ESC +:x (para salvar e sair do editor Vim).

Ajustar script de inicialização
Acesse de acordo com arquitetura do servidor Linux
x86: #vim /opt/sonarqube-5.1.2/bin/linux-x86-32/sonar.sh
x64: #vim /opt/sonarqube-5.1.2/bin/linux-x86-64/sonar.sh
Adicione as linhas abaixo, substituindo a arquitetura de acordo com servidor Linux.
SONAR_HOME=/opt/sonarqube-5.1.2
PLATAFORMA=linux-x86-32
E editar as linhas 28 e 29.
WRAPPER_CMD="${SONAR_HOME}/bin/${PLATAFORMA}/wrapper"
WRAPPER_CONF="${SONAR_HOME}/conf/wrapper.conf"
ESC +:x (para salvar e sair do editor Vim).

Startando o SonarQube
Utilize de acordo com a arquitetura do seu servidor Linux
x86: #chmod +x /opt/sonarqube-5.1.2/bin/linux-x86-32/sonar.sh
#/opt/sonarqube-5.1.2/bin/linux-x86-32/sonar.sh start
x64: #chmod +x /opt/sonarqube-5.1.2/bin/linux-x86-64/sonar.sh
#/opt/sonarqube-5.1.2/bin/linux-x86-64/sonar.sh start

Acesse no browser: http://IPSERVIDOR:9000/sonar
Feito!