GERÊNCIA E QUALIDADE DE SOFTWARE_sem2

Prévia do material em texto

2 
Compilação e integração automatizadas 
 
Olá, estudante! 
Olá, estudante! 
Nesta semana, continuaremos os estudos da disciplina Gerência e Qualidade de Software, avançando em seu 
objetivo de “conhecer e aplicar os conceitos práticos relacionados à qualidade de software e as diferentes 
métricas para a sua avaliação”. 
Para isso, cobriremos um assunto com uma visão bastante prática, a automação de compilação e integração 
de software por meio de três diferentes ferramentas bem conhecidas por profissionais da engenharia de 
software – as ferramentas Maven, Gradle e CMake. 
Bom estudo para você! 
Objetivos de aprendizagem 
Ao final dessa semana, você deverá ser capaz de: 
• Conhecer a automação de compilação e integração de software via o uso das ferramentas Maven, 
Gradle e Cmake. 
 
Orientação de estudos 
Nesta semana, há três videoaulas, sendo três demonstrações básicas do uso de cada uma das três ferramentas 
cobertas no escopo desta disciplina, ou seja, Maven, Gradle e CMake. Você pode assisti-las nessa ordem. Há 
também materiais-base e materiais de apoio para ajudar a instalar, configurar e usar essas ferramentas já que 
o objetivo é que você adquira uma visão prática delas. 
 
Automação de compilação e integração com Maven 
Objetivos da aula 
Conhecer a automação de compilação e integração de software via o uso de uma 
ferramenta (ferramenta Maven). 
Maven 
Ferramenta de “automação de compilação” 
• Usada primariamente em Java, mas também outras linguagens 
• POM (Project Object Model), arquivo XML descreve o projeto de software sendo construído: 
• Dependências sobre módulos e componentes externos 
• Ordem de compilação 
• Diretórios 
• Plug-ins necessários 
• Objetivos pré-definidos para realizar certas tarefas bem definidas como compilação de código e empacotamento 
 
Ciclo de vida de construção 
1. process-resources mvn process-resources 
2. compile mvn compile 
3. process-test-resources mvn process-test-resources 
4. test-compile mvn test-compile 
5. test mvn test 
6. package mvn package 
7. install mvn install 
8. deploy mvn deploy 
 
PERGUNTA 1 
Uma característica da ferramenta Maven apresentada videoaula é: 
o ser uma ferramenta para automação de testes. 
o ser usada apenas em Java. 
 
o ter como base um arquivo XML para definir suas regras. 
o o projeto de software sendo construído deve incluir apenas dependências, ordem de compilação e 
diretórios. 
o ser baseada em um arquivo chamado OPM. 
 
Você acertou! Essa é a alternativa correta. O arquivo base POM é um arquivo XML. 
 
Automação de compilação e integração com Gradle 
Objetivos da aula 
Conhecer a automação de compilação e integração de software via o uso de uma ferramenta 
(ferramenta Gradle). 
 
 
PERGUNTA 1 
Uma característica da ferramenta Gradle apresentada videoaula é: 
o ter sido usado como inspiração para o Maven. 
o ter iniciado com C/C++, mas hoje suportar também 
Java. 
o usar uma linguagem de propósito geral. 
o ter como base um arquivo XML para definir suas regras. 
o suportar compilações incrementais. 
 
Automação de geração com CMake 
Objetivos da aula 
Conhecer a automação de compilação e integração de software via o uso de uma 
ferramenta (ferramenta CMake) 
 
PERGUNTA 1 
Uma característica da ferramenta Gradle apresentada videoaula é: 
o ser mais recente que Maven e Gradle. 
o oferecer menos funcionalidades que Maven e Gradle. 
o não ser possível executá-lo em linha de comando, no terminal. 
o ser focado em programas Java. 
o ser focado no Unix. 
 
Instalando, configurando e usando o Maven para gerenciar suas dependências e seus 
projetos Java 
 24/06/2014 Arquitetura de Software, Java 
Este artigo é uma introdução ao Maven, uma ferramenta de gerenciamento de dependências e ciclo 
de vida de um projeto em Java. 
Para usar o Maven, você precisa ter o JDK instalado. Você também pode integrá-lo à sua IDE. Para 
saber como instalar o JDK e o Eclipse, consulte os seguintes artigos: 
• Instalando e Configurando o Java Development Kit 7 para Desenvolvimento 
• Instalando, Configurando e Usando o Eclipse Kepler 
O que é o Maven? 
O Maven é uma ferramenta de gerenciamento de dependências e do ciclo de vida de projetos de 
software no sentido técnico. Isso inclui: 
• Facilitar a compilação do código, o empacotamento (JAR, WAR, EAR, …), a execução de 
testes unitários, etc. 
• Unificar e automatizar o processo de geração do sistema. Nada mais de uma coleção de 
passos e scripts a serem executados manualmente. 
• Centralizar informações organizadas do projeto, incluindo suas dependências, resultados 
de testes, documentação, etc. 
• Reforçar boas práticas de desenvolvimento, tais como: separação de classes de teste das 
classes do sistema, uso de convenções de nomes e diretórios, etc. 
• Ajuda no controle das versões geradas (releases) dos seus projetos. 
http://luizricardo.org/2014/06/instalando-configurando-e-usando-o-maven-para-gerenciar-suas-dependencias-e-seus-projetos-java/
http://luizricardo.org/2014/06/instalando-configurando-e-usando-o-maven-para-gerenciar-suas-dependencias-e-seus-projetos-java/
http://luizricardo.org/2014/06/instalando-configurando-e-usando-o-maven-para-gerenciar-suas-dependencias-e-seus-projetos-java/
http://luizricardo.org/categoria/arquitetura/
http://luizricardo.org/categoria/desenvolvimento/java/
http://maven.apache.org/
http://luizricardo.org/2013/11/instalando-e-configurando-o-java-development-kit-7-para-desenvolvimento/
http://luizricardo.org/2013/11/instalando-configurando-e-usando-o-eclipse-kepler/
Conceitos importantes 
Artefato (artifact) 
Um artefato é geralmente um arquivo JAR que fica no repositório do Maven, mas pode ser de outro 
tipo. 
Cada artefato é identificado através dos seguintes elementos: 
• Grupo: é como o endereço do site ao contrário, 
como br.com.starcode, org.apache, com.google, com.ibm, etc. 
• Identificador único de artefato: geralmente é o nome do projeto. Ele deve ser único por 
grupo. 
• Número de versão: a versão do projeto, como 1.4.2 ou 3.0. Se houver o sufixo -
SNAPSHOT (0.0.1-SNAPSHOT, por exemplo) significa que o projeto está em 
desenvolvimento e o pacote pode ser alterado. 
• Tipo do projeto: jar, war, ear, pom (projeto de configuração). 
• Classificador: identificação opcional para diferenciar variações da mesma versão. Por 
exemplo, se o programa é compilado para diferentes versões do Java podemos usar os 
classificadores jdk4 e jdk6. Se há variações específicas para Sistemas Operacionais, 
podemos ter os classificadores linux e windows. 
Repositório local 
É um diretório em seu PC onde os artefatos são armazenados após baixados de um repositório 
remoto na internet ou na intranet. Você também pode instalar os artefatos dos seus projetos nesse 
repositório executando o install do Maven. Continue lendo para entender o que é isso. 
O repositório possui uma estrutura padrão onde o Maven consegue encontrar os artefatos através da 
identificação do mesmo. 
Repositório remoto 
Consiste numa aplicação que disponibiliza artefatos do Maven. Pode ser um repositório público na 
Internet, onde criadores de bibliotecas e frameworks disponibilizam seus artefatos, ou pode ser um 
repositório privado da empresa, disponível na intranet. 
Existe um repositório central que já vem configurando no Maven, mas algumas empresas criam seus 
próprios repositórios. Inclusive você pode criar o seu instalando o Artifactory ou Nexus num servidor. 
Quando adicionamos esses repositórios remotos em nossa instalação do Maven, ele é capaz de 
localizar e baixar automaticamente as dependências através da identificação do artefato. 
Arquivo POM 
O arquivo pom (pom.xml) é a configuração principal do Maven e estará presente em todo projeto. 
Nele você declara a identificação do seu projeto (que após gerado será também um artefato Maven), 
as dependências, repositórios adicionais,etc. 
http://www.jfrog.com/home/v_artifactory_opensource_overview
http://www.sonatype.org/nexus/
Há um arquivo pom por projeto, mas ele pode herdar configurações de um parent pom, isto é, como 
se houvesse um projeto "pai". 
Ciclo de vida padrão do Maven 
O Maven possui um ciclo de vida padrão. Cada passo do ciclo de vida é chamado de Goal e possui 
plugins específicos. Os mais importantes são: 
• validate: valida o projeto e se as informações necessárias para os próximos passos estão 
disponíveis, como as dependências por exemplo. 
• compile: compila o código-fonte. 
• test: executa os testes unitários (JUnit, por exemplo). 
• package: empacota o código compilado em um JAR, WAR, etc. 
• integration-test: executa os testes de integração. 
• install: adiciona o pacote gerado ao repositório local, assim outros projetos na mesma 
máquina podem usar essa dependência. 
• deploy: copia o pacote final para o repositório remoto, disponibilizando-o para outros 
desenvolvedores e outros projetos. 
Os itens acima, nessa ordem, são passos comuns para geração de uma versão de qualquer sistema, 
não é mesmo? 
No Maven, você pode configurar detalhadamente cada um desses passos e até incluir novos. Por 
exemplo, alguns frameworks que geram código-fonte usam um goal generate-sources para fazer 
isso. 
Além disso, não é necessário executar todos os passos sempre. Você pode escolher qual deseja 
executar num determinado momento, mas o Maven sempre executará todos os passos anteriores. 
Por exemplo, enquanto você está desenvolvendo um módulo, a cada alteração pode executar o 
passo test para executar a validação, compilação e então os testes unitários. Então você só precisa 
executar os passos posteriores quando tiver concluído o trabalho. 
Para maiores informações sobre o ciclo de vida, consulte a documentação. 
Estrutura padrão de um projeto Maven 
A estrutura padrão do projeto inclui boas práticas (como separar as classes de teste das classes do 
sistema) e facilita aos novos desenvolvedores encontrar o que eles querem, já que todos os projetos 
seguirão uma estrutura semelhante. 
Veja a seguir os principais diretórios utilizados: 
• src/main/java: aqui fica o código-fonte do sistema ou biblioteca. 
• src/main/resources: arquivos auxiliares do sistema, como .properties, XMLs e 
configurações. 
• src/main/webapp: se for uma aplicação web, os arquivos JSP, HTML, JavaScript CSS vão 
aqui, incuindo o web.xml. 
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
• src/test/java: as classes com seus testes unitários ficam aqui e são executadas 
automaticamente com JUnit e TestNG. Outros frameworks podem exigir configuração 
adicional. 
• src/test/resources: arquivos auxiliares usados nos testes. Você pode ter properties e 
configurações alternativas, por exemplo. 
• pom.xml: é o arquivo que concentra as informações do seu projeto. 
• target: é o diretório onde fica tudo que é gerado, isto é, onde vão parar os arquivos 
compilados, JARs, WARs, JavaDoc, etc. 
Para ver mais detalhes sobre a estrutura de diretórios do Maven, consulte a documentação. 
Usando o Maven em projetos já existentes 
Você pode ter ficado desapontado com a estrutura anterior, pois estava pensando em usar o Maven 
em um projeto que já começou, mas não quer ou não pode mudar a estrutura de pastas atuais. 
Saiba que o Maven é flexível e permite alterar toda a estrutura padrão. 
Por exemplo, é comum usar a pasta src para os fontes, ao invés de src/main/java. Para ajustar 
isso, basta adicionar uma tag <sourceDirectory> dentro da tag <build>, assim: 
<project> 
 ... 
 <build> 
 <sourceDirectory>src</sourceDirectory> 
 ... 
 </build> 
 ... 
</project> 
Não vou ir fundo nessa questão, mas se o leitor tiver um projeto em condições semelhantes, sugiro 
uma leitura mais completa da documentação, começando com Using Maven When You Can’t Use the 
Conventions. 
É claro que nem tudo é tão simples. Muitos projetos usam estruturas tão diferentes que se exige a 
refatoração desta estrutura. 
Benefícios do Maven 
A adoção do Maven no desenvolvimento traz de imediato os seguintes benefícios: 
Centralização das informações 
O Maven centraliza as informações dos projetos no arquivo pom. 
Sendo assim, não é preciso configurar várias ferramentas, build scripts, servidores e IDEs durante o 
desenvolvimento. O Maven segue o conceito DRY (Don’t Repeat Yourself). 
Além disso, o Maven também disponibiliza formas de analisar o projeto. Por exemplo, 
o goal dependency:analyze exibe as dependências declaradas que não estão sendo usadas e as 
usadas via terceiros, mas não declaradas no pom. 
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
http://maven.apache.org/guides/mini/guide-using-one-source-directory.html
http://maven.apache.org/guides/mini/guide-using-one-source-directory.html
Padronização do ambiente de desenvolvimento 
Através da especificação do projeto, incluindo suas características e dependências, o Maven constrói a 
estrutura necessária do projeto, baixando automaticamente as versões corretas das dependências 
(JARs, por exemplo) de um repositório central ou de um repositório privado (contendo sistemas da 
empresa). 
Você não precisa entrar no site de cada biblioteca e framework usado e então fazer manualmente o 
download e adicionar os jars no seu classpath. 
Dessa forma, cada desenvolvedor consegue configurar rapidamente um ambiente para 
desenvolvimento com a garantia de que esse ambiente é igual ao dos outros desenvolvedores. 
Gerenciamento de dependências 
Como já mencionei, o Maven faz o download automático de dependências para o projeto e os 
adiciona ao classpath do seu projeto. 
Cada dependência pode ter também as suas próprias dependências. Elas são 
chamadas dependências transitivas. O Maven resolve essa árvore de dependências e traz tudo o 
que você precisa. 
Em alguns casos, pode haver problemas de conflitos, no caso da árvore de dependências incluir 
versões diferentes de um mesmo artefato. O Maven vem com mecanismos para resolver isso. 
Facilidade de compreensão do projeto 
Ao usar a convenção de diretórios sugerida pelo Maven os desenvolvedores terão mais facilidade em 
compreender a estrutura do projeto, afinal todos os projetos seguirão uma estrutura básica de 
diretórios, como vimos anteriormente. 
Automação 
O Maven gerencia o ciclo de vida da aplicação. Após configurar um projeto, você será capaz de 
executar comandos que vão desde a compilação até a geração de documentação (Javadoc) e um site 
padrão contendo informações sobre o projeto. 
Uma vez feita a configuração necessária, o projeto pode ser baixado e compilado sem nenhum 
esforço. Novas versões podem ser geradas em servidores de Integração Contínua e testadas 
automaticamente sempre que necessário. 
Um alerta 
Embora os tópicos anteriores tenham enumerado diversas vantagens do uso do Maven, este não é 
uma "bala de prata", ou seja, uma solução mágica para o projeto. 
Dependendo da complexidade do projeto, pode ser bem complicado criar uma configuração 
adequada para ao Maven. 
Além disso, o Maven não irá livrá-lo de problemas como: 
Incompatibilidade de dependências 
O projeto depende dos frameworks A e B. O framework A depende a versão 1.0 da biblioteca C. O 
framework B depende da versão 2.0 da biblioteca C. 
O Maven não vai resolver sozinho isso, mas facilita muito a resolução do problema já que podemos 
usar as informações do mecanismo de resolução de dependências para identificar os conflitos. 
Algumas tecnologias simplesmente não vão funcionar bem com o Maven 
Alguns autores de frameworks ou arquiteturas inventam o seu próprio jeito de trabalhar. Isso 
significa que para usar o Maven é necessário alguma adaptação, o que nem sempre é trivial. 
No entanto, é possível escrever plugins para o Maven que façam o trabalho para você. Geralmente a 
comunidade de cada framework,se não os próprios autores, já terão resolvido esse problema. 
Embora existam casos em que essas soluções acrescentem novas limitações. 
Ódio do Maven 
A verdade é que existe muita gente que odeia o Maven por ter vivido experiências ruins com ele, 
principalmente no início. Infelizmente, não sei se este artigo terá o poder de curá-lo de traumas 
passados ao tentar usar o Maven sem a devida orientação. 
No entanto, não deixe que isso influencie você neste momento. Mesmo que não pretenda usar o 
Maven em seus projetos, vale a pena conhecê-lo. Você pode ser obrigado a usá-lo na empresa ou 
mesmo num projeto opensource de que vai participar. 
Se você não gosta do Maven, tenha duas coisas em mente: 
1. Existem várias alternativas, desde scripts Ant até outras ferramentas de resolução de 
dependências mais avançadas como o Graddle. 
2. Embora algumas pessoas atinjam um excelente nível de produtividade sem o Maven, se 
considerarmos um contexto mais amplo, como um projeto que com mais de meia dúzia de 
desenvolvedores, alguns deles novatos, o Maven pode trazer mais vantagens que 
desvantagens se bem configurado por um desenvolvedor experiente. 
Instalando o Maven 
Acesse a página do Maven e clique no item Download do menu. 
A página disponibiliza diferentes versões para diferentes ambientes. Baixe o arquivo da última versão 
de acordo com seu sistema operacional. Destaquei na imagem a versão zip para Windows que usarei 
neste exemplo: 
http://www.gradle.org/
http://maven.apache.org/
http://maven.apache.org/download.cgi
 
A versão mais atual do Maven na data de criação deste tutorial é 3.2.1. O pacote baixado é 
nomeado apache-maven-3.2.1-bin.zip. Veja o arquivo aberto no 7-Zip: 
 
Descompacte o conteúdo para a pasta c:\starcode\. 
 
Configura o resultado na imagem a seguir: 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/011.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/021.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/031.png
 
Configurando o Maven 
O Maven é configurado através do arquivo settings.xml que fica no 
diretório c:\starcode\apache-maven-3.2.1\conf. 
Abra o arquivo usando um editor avançado, como o Notepad++. Você vai ver que existem diversos 
blocos de XML comentados com possíveis configurações e explicações sobre elas. 
Em um ambiente simples você não vai precisar mexer em muita coisa. Porém, vamos ver alguns 
pontos mais importantes. 
Proxy 
É muito comum precisarmos autenticar o acesso à internet em um Proxy quando estamos no 
trabalho. Procure a tag <proxy>, a qual deve estar comentada no arquivo de configuração. O trecho é 
o seguinte: 
<proxy> 
 <id>optional</id> 
 <active>true</active> 
 <protocol>http</protocol> 
 <username>proxyuser</username> 
 <password>proxypass</password> 
 <host>proxy.host.net</host> 
 <port>80</port> 
 <nonProxyHosts>local.net|some.host.com</nonProxyHosts> 
</proxy> 
Se você tem um proxy na sua rede, mova o bloco acima para fora do comentário, então substitua os 
parâmetros de acordo com seu ambiente. Mantenha a tag <proxy> dentro de <proxies>. 
Veja abaixo um exemplo de uso: 
<proxies> 
 <proxy> 
 <id>proxy</id> 
 <active>true</active> 
 <protocol>http</protocol> 
http://notepad-plus-plus.org/
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/041.png
 <host>proxy.intranet.empresa.com</host> 
 <port>8080</port> 
 <nonProxyHosts>localhost,127.*,192.*</nonProxyHosts> 
 </proxy> 
</proxies> 
Local do repositório 
O Maven utiliza um diretório local para baixar os artefatos da internet. O diretório padrão fica dentro 
pasta do usuário, na pasta .m2. Um exemplo no Windows é c:\users\luiz\.m2\repository. 
Entretanto, tenho o hábito de mudar esse diretório para junto de meus arquivos de desenvolvimento. 
Para isso, basta editar o settings.xml, movendo a tag <localRepository> para fora do 
comentário e adicionando o caminho, por exemplo: 
<localRepository>c:\starcode\apache-maven-3.2.1\repo</localRepository> 
Não se esqueça de criar o diretório especificado caso o mesmo não exista. 
Configurando as variáveis de ambiente 
Para usar o Maven em linha de comando você deve adicionar o caminho para os executáveis 
ao PATH do ambiente. No Windows, pressione Ctrl+Break para abrir a tela de informações do do 
sistema. 
 
Clique na opção Configurações avançadas do sistema, à esquerda da janela. 
 
Na aba Avançado da tela de Propriedades do Sistema, clique em Variáveis de Ambiente.... 
http://proxy.intranet.empresa.com/
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/05-configurar-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/06-configurar-maven.png
 
Você pode adicionar a variável de ambiente apenas para o usuário atual ou globalmente para todo o 
sistema. Faça o que for melhor para o seu caso. Alguns ambientes corporativos impedem o acesso à 
configuração de sistema por questões de segurança, então você terá que configurar apenas seu 
usuário. 
Clique em Novo... e crie a variável M2_HOME com o valor apontando para o diretório base do Maven. 
No nosso exemplo o valor é c:\starcode\apache-maven-3.2.1. 
 
Clique em OK para criar a variável. 
 
Agora vamos incluir o diretório com os executáveis do Maven ao PATH. Localize a entrada, selecione-a 
e clique em Editar.... 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/07-configurar-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/08-configurar-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/09-configurar-maven.png
 
Adicione ao final um ponto e vírgula e o caminho para a pasta bin do Maven (;%M2_HOME%\bin), 
assim: 
 
Clique em OK para confirmar a edição e OK novamente para confirmar as alterações nas variáveis do 
sistema. 
Vamos então testar a instalação. Abra o CMD (linha de comando) e digite mvn -version. Você deve 
ver algo como na figura abaixo: 
 
Se ocorreu algum problema, verifique se você tem o Java instalado e configurado corretamente, 
incluindo as variáveis de ambiente JAVA_HOME e PATH incluindo o Java. Caso tenha dúvidas, acesse o 
artigo citado no início sobre a instalação do JDK. 
Usando o Maven 
Usando a instalação do Maven no Eclipse 
Para integrar o Maven e Eclipse eu aconselho o plugin M2E. Note que o M2E é um plugin do Eclipse 
que faz integração com o Maven. 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/10-configurar-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/11-configurar-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/12-configurar-maven.png
Existe também o Maven Eclipse Plugin, aquele onde se digita eclipse:eclipse para gerar um 
projeto para o Eclipse. Este é um plugin do Maven que simplesmente gera os arquivos de 
configuração necessários para a IDE. Não confunda os dois. 
A distribuição Eclipse for JEE Developers já vem com o plugin M2E e uma instalação interna do 
Maven. Veja como instalar e usar o Eclipse acessando o artigo citado no início. 
Se você tem uma versão diferente do Eclipse, use o menu Help > Eclipse Marketplace..., 
pesquise por M2E e instale o plugin. 
Com o plugin instalado e o Eclipse aberto, acesse o menu Window > Preferences... e vá até a 
opção Maven > Installations. 
 
Veja que já existe uma instalação "embarcada", mas com uma versão desatualizada. Vamos adicionar 
o nosso Maven. 
Clique em Add... e selecione a pasta com a nossa instalação, no caso: c:\starcode\apache-
maven-3.2.1. 
 
Note que ele já encontrou nosso arquivo de configuração. 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/01-maven-eclipse.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/02-maven-eclipse.png
Vá até o menu User Settings. Há um warning lá dizendo que a configuração do usuário não existe. 
Você pode criarum outro settings.xml na pasta indicada ou simplesmente use um artifício (que eu 
sempre uso), que é definir o mesmo arquivo da configuração global. 
 
Caso não tenha entendido, o Maven possui um arquivo de configuração global que afeta diretamente 
a instalação e fica na pasta conf. Entretanto, cada usuário do sistema pode ter um arquivo próprio e 
sobrescrever as configurações globais que ele desejar. No entanto, se você é o único usuário do 
computador, não é necessário ter os dois arquivos. 
Criando um projeto Maven simples no Eclipse 
Com o Maven configurado, vamos criar um novo projeto no Eclipse. Acesse o menu File > New > 
Maven Project. Selecione a opção Create a simple project (skip archetype 
selection) e clique clique em Next >. 
 
Vamos preencher a identificação do projeto, que nada mais é do que a identificação de um artefato. 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/03-maven-eclipse.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/01-projeto-simples.png
 
O Group Id para o exemplo será br.com.starcode e o Artifact Id será teste-maven-01. A 
versão e o tipo de artefato (Packaging) já devem estar preenchidos, então simplesmente deixe como 
está. O nome e a descrição são opcionais. 
Clique em Finish para ver o projeto criado. 
Note que ele ainda não está definido com as configurações de um projeto Java, então clique com o 
botão direito sobre o projeto, acesse o menu Maven > Update Project.... 
 
Clique em OK para atualizar o projeto com as configurações do Maven e agora temos a estrutura 
característica. 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/02-projeto-simples.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/03-projeto-simples.png
 
Adicionando manualmente uma dependência 
Agora vou ilustrar como podemos adicionar algumas dependências ao projeto. Acesse o 
site mvnrepository.com, que contém um índice das dependências disponíveis no repositório do 
Maven. Pesquise por commons-lang. 
 
Selecione o item Apache Commons Lang, como indicado na imagem abaixo: 
http://mvnrepository.com/
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/04-projeto-simples.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/05-projeto-simples.png
 
Clique sobre a última versão (3.3.2 na data em que escrevo o artigo). 
 
Selecione e copie a identificação do artefato, conforme a imagem abaixo: 
 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/06-projeto-simples.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/07-projeto-simples.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/08-projeto-simples.png
Agora volte ao Eclipse e clique duas vezes sobre o arquivo pom.xml para editá-lo. Provavelmente o 
editor foi aberto no aba Overview (veja abaixo do editor) com diversos campos e informações sobre 
o projeto. 
Clique na aba pom.xml para mostrar o código fonte. 
 
Adicione a tag <dependencies> logo abaixo da tag <description> e cole o conteúdo do site dentro 
dela. 
Dica: Pressione CTRL+A para selecionar todo o conteúdo do arquivo e depois CTRL+I para indentar 
(tabular) o arquivo. 
 
O conteúdo do pom.xml deve ser o seguinte: 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XM
LSchema-instance" 
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/m
aven-4.0.0.xsd"> 
 <modelVersion>4.0.0</modelVersion> 
 <groupId>br.com.starcode</groupId> 
http://maven.apache.org/POM/4.0.0
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2001/XMLSchema-instance
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd
http://maven.apache.org/xsd/maven-4.0.0.xsd
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/09-projeto-simples.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/10-projeto-simples.png
 <artifactId>teste-maven-01</artifactId> 
 <version>0.0.1-SNAPSHOT</version> 
 <name>Teste Maven 01</name> 
 <description>Um teste de projeto simples com o maven</description> 
 <dependencies> 
 <dependency> 
 <groupId>org.apache.commons</groupId> 
 <artifactId>commons-lang3</artifactId> 
 <version>3.3.2</version> 
 </dependency> 
 </dependencies> 
</project> 
Salve o arquivo. O plugin M2E irá identificar a alteração, baixar automaticamente a dependência do 
repositório central para o seu repositório local e adicioná-la ao classpath do projeto. 
Confira a entrada Maven Dependencies na imagem a seguir: 
 
Pronto! Agora você já pode usar qualquer classe da biblioteca Apache Commons Lang. 
Fiz uma classe de exemplo (File > New > Other..., selecione Class), com o seguinte conteúdo: 
package br.com.starcode.testemaven01; 
 
import org.apache.commons.lang3.StringUtils; 
 
public class ClasseDeTeste { 
 
 public static void main(String[] args) { 
 
 System.out.println(StringUtils.capitalize("luiz")); 
 
 } 
 
http://commons.apache.org/proper/commons-lang/
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/11-projeto-simples.png
} 
Executei o método main clicando com o botão direito sobre a classe, menu Run As > Java 
Application. Veja o resultado: 
 
Executando os passos (goals) do Maven 
Vamos supor que estamos construindo uma nova biblioteca. Precisaremos testá-la (test), empacotá-
la (package) num jar e distribuí-la (deploy) para o uso de terceiros, não é mesmo? O Maven nos ajuda 
grandemente com esses passos naturais do ciclo de vida de um projeto. 
Vamos usar nosso projeto de exemplo e criar uma classe utilitária chamada SuperUtil: 
package br.com.starcode.testemaven01; 
 
import org.apache.commons.lang3.StringEscapeUtils; 
 
public class SuperUtil { 
 
 /** 
 * Possibilita exibir um texto contendo HTML no navegador sem ataques XSS. 
 * @param html Entrada do usuário (pode ter HTML, mas não deve ser renderizado, som
ente exibido) 
 * @return Texto sem posíveis tags HTML 
 */ 
 public static String escapeHTML(String html) { 
 return StringEscapeUtils.escapeHtml4(html); 
 } 
 
} 
Veja no Eclipse: 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/12-projeto-simples.png
 
Vamos ainda criar um teste unitário para nossa classe, as primeiro temos que adicionar a 
dependência do JUnit ao nosso projeto. Para isso vá até o site mvnrepository.com e pesquise 
por junit. Vá até a última versão, copie o trecho do XML e adicione na seção de dependências do 
seu pom.xml. 
Adicione também a tag <scope>test</scope> à esta dependência, para informar ao Maven que ela 
somente será usada no teste. Sim, o Maven é “esperto” e não incluirá, por exemplo, o JUnit na 
pasta WEB-INF/lib de uma aplicação web. 
Veja como ficou o pom.xml: 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XM
LSchema-instance" 
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/m
aven-4.0.0.xsd"> 
 <modelVersion>4.0.0</modelVersion> 
 <groupId>br.com.starcode</groupId> 
 <artifactId>teste-maven-01</artifactId> 
 <version>0.0.1-SNAPSHOT</version> 
 <name>Teste Maven 01</name> 
 <description>Um teste de projeto simples com o maven</description> 
 <dependencies> 
 <dependency> 
 <groupId>org.apache.commons</groupId> 
 <artifactId>commons-lang3</artifactId> 
 <version>3.3.2</version> 
 </dependency> 
 <dependency> 
 <groupId>junit</groupId> 
 <artifactId>junit</artifactId> 
 <version>4.11</version> 
 <scope>test</scope> 
 </dependency> 
 </dependencies> 
</project> 
Ao salvar o arquivo o Maven deve baixar o JUnit automaticamente. 
http://mvnrepository.com/
http://mvnrepository.com/artifact/junit/junit/4.11http://maven.apache.org/POM/4.0.0
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2001/XMLSchema-instance
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd
http://maven.apache.org/xsd/maven-4.0.0.xsd
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/01-executando-com-maven.png
Agora crie a classe de teste SuperUtilTest em src/test/java: 
package br.com.starcode.testemaven01; 
 
import org.junit.Assert; 
import org.junit.Test; 
 
public class SuperUtilTest { 
 
 @Test 
 public void escapeHTMLTest() { 
 
 String escapedHtml = SuperUtil.escapeHTML("<script>alert(1);</script>"); 
 String expected = "&lt;script&gt;alert(1);&lt;/script&gt;"; 
 Assert.assertEquals(expected, escapedHtml); 
 
 } 
 
} 
Caso queira executar o teste já, clique com o botão direito sobre a classe e acesse o menu Run As > 
JUnit Test: 
 
Confira o resultado: 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/02-executando-com-maven.png
 
Sucesso! 
Imagine agora que tenhamos criado diversas classes e métodos. Temos uma versão beta de nossa 
biblioteca. 
Vamos testar o projeto usando o Maven. Clique no projeto com o botão direito e na opção Run As > 
Maven test: 
 
Na primeira execução o Maven vai baixar diversos plugins e dependências internas para a execução 
do projeto. Aguarde um pouco e confira o resultado de todos os testes do projeto: 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/03-executando-com-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/04-executando-com-maven.png
 
Ok, agora vamos gerar um JAR do projeto. Clique no projeto com o botão direito e na opção Run As 
> Maven build.... Isso é necessário porque não é uma opção pronta para o passo package. Vá até 
o campo Goals e digite package. 
 
Clique em Run e aguarde. 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/05-executando-com-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/06-executando-com-maven.png
 
Se você observar o log no Console notará que os testes foram executados. Lembra que eu disse que 
os passos anteriores sempre são executados? Espero que agora tenha entendido melhor. 
Note a última linha antes das palavras BUILD SUCCESS. Ali está o caminho do Jar gerado. Ele foi 
gerado dentro da pasta target do projeto. 
Selecione a pasta target e Pressione F5 para atualizá-la. Abra-a clicando na seta à esquerda e 
confira: 
 
Vamos agora executar o install, isto é, instalar o jar no repositório local. Clique no projeto com o 
botão direito e na opção Run As > Maven install. Aguarde um pouco e veja o resultado: 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/07-executando-com-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/08-executando-com-maven.png
 
As duas últimas linhas antes da mensagem de sucesso demonstram os locais onde o Jar e o seu 
arquivo POM foram instalados: 
[INFO] Installing D:\starcode\workspaces\workspace_demo\teste-maven-01\target\teste-maven-01-0.0.1-
SNAPSHOT.jar to c:\starcode\apache-maven-3.2.1\repo\br\com\starcode\teste-maven-01\0.0.1-
SNAPSHOT\teste-maven-01-0.0.1-SNAPSHOT.jar 
[INFO] Installing D:\starcode\workspaces\workspace_demo\teste-maven-01\pom.xml to c:\starcode\apache-
maven-3.2.1\repo\br\com\starcode\teste-maven-01\0.0.1-SNAPSHOT\teste-maven-01-0.0.1-SNAPSHOT.pom 
Vamos abrir o diretório do repositório local e dar uma olhadinha: 
 
Agora você pode usar este artefato em outros projetos na sua máquina local, adicionando a seguinte 
dependência: 
<dependency> 
 <groupId>br.com.starcode</groupId> 
 <artifactId>teste-maven-01</artifactId> 
 <version>0.0.1-SNAPSHOT</version> 
</dependency> 
Qualquer projeto com essa dependência vai usar o nosso jar gerado e, automaticamente, incluir 
também o jar do Apache Commons Lang que definimos em nosso projeto. 
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/09-executando-com-maven.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/10-executando-com-maven.png
Analisando as dependências 
Vamos aprender a analisar as dependências de um projeto. 
Abra novamente o seu arquivo pom.xml e vá até a aba Dependency Hierarchy. Você deve estar 
vendo isso: 
 
Abaixo, mais um exemplo de dependências extraído da minha biblioteca T-Rex: 
 
Usando o Maven em linha de comando 
Tudo o que fizemos anteriormente através da IDE pode ser feito via linha de comando. É importante 
entender isso porque quando o projeto for compilado em um servidor de Integração Contínua, por 
exemplo, ele não contará com as facilidades do plugin que usamos. 
Irei ilustrar a seguir a execução do goal install via linha de comando. 
O primeiro passo é abrir o CMD e ir até o diretório do projeto. Então basta digitar o comando maven 
install. 
 
Configura o resultado da execução: 
 
 
https://github.com/utluiz/t-rex
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/01-maven-dependencies.png
http://luizricardo.org/wordpress/wp-content/upload-files/2014/06/maven-dependency-hierarchy.png
Pronto! 
Explicando: nós adicionamos o Maven ao path do sistema, lembra? maven é o nome do executável do 
Maven e install é o goal que você deseja executar. Também há usar o executável mvn, que é 
apenas um atalho para evitar digitar mais caracteres. 
Da mesma forma, poderíamos executar mvn test ou mvn package como fizemos nos tópicos acima 
via menu do Eclipse para ativar os respectivos Goals. 
Um goal muito importante ainda não mencionado é o clean, que serve para limpar todos os arquivos 
gerados da pasta target. Ele é muito importante para limpar eventual “sujeira” de gerações 
anteriores. 
Quando estiver tendo problemas estranhos ou for gerar uma versão "oficial", sempre use comandos 
como mvn clean install ou mvn clean deploy para garantir uma geração "limpa". 
Note que você pode especificar vários goals simultaneamente para o Maven executar. Nos exemplos 
acima, o Maven vai primeiro limpar o projeto e depois executar o install ou o deploy. 
Passando parâmetros para o Maven 
Há ainda situações onde precisamos ajustar a execução do Maven através de parâmetros. 
Por exemplo, em certas ocasiões queremos gerar um jar ou war para testes, porém o build do Maven 
falha porque um teste unitário terminou em erro. 
Para resolver essa situação sem excluir o teste unitário, é possível configurar o Maven para “pular” os 
testes com o seguinte comando: 
mvn -DskipTests clean install 
 
Configura o resultado da execução: 
 
 
O mesmo resultado pode ser obtido no Eclipse clicando com o botão direito sobre o projeto e indo no 
menu Run As > Maven build..., digitando clean install no campo Goals e selecionando a 
opção Skip Tests. 
Distribuindo seu projeto 
Os próximos passos incluiriam disponibilizar o jar para outros desenvolvedores através 
do goal deploy. Em um deploy, o Maven envia seu jar para um Repositório Remoto. Entretanto, isso 
exige várias configurações adicionais e as devidas permissões. 
Disponibilizar seu projeto no repositório central do Maven exige que seu projeto seja opensource e 
que você solicite as permissões necessárias. Caso você queira fazer isso, siga os passos disponíveis 
neste link. 
Já dentro de uma empresa geralmente se configura um servidor para conter um repositório com os 
artefatos da empresa. Existem aplicações gratuitas que podem ser usadas para isso, como 
o Artifactory ou o Nexus. 
As configurações necessárias para o deploy num repositório remoto estão fora do escopo deste 
artigo, mas existem várias referências disponíveis na web. 
https://central.sonatype.org/pages/ossrh-guide.html
https://central.sonatype.org/pages/ossrh-guide.html
http://www.jfrog.com/home/v_artifactory_opensource_overview
http://www.sonatype.org/nexus/
Leitura adicional 
Usar o Maven para desenvolver projetos pessoais é relativamente fácile este artigo cobre o 
necessário para isso. Entretanto, não deixe de estudar o material oficial e, aos poucos, ir entendendo 
os mecanismos do Maven para usá-lo em projetos maiores: 
• Site oficial do Maven 
• Maven in 5 Minutes 
• Maven Getting Started Guide 
Considerações finais 
Usar o Maven pode ser confuso a princípio, mas traz diversos benefícios. 
Em curto prazo ele ajuda você a gerenciar as dependências e organizar seus projetos. 
Em médio prazo você poderá ter um controle muito bom de versões e releases, além de um padrão 
maduro para seus projetos. 
Em longo prazo o Maven possibilitará a Integração Contínua de seus projetos. Será necessário um 
esforço considerável, mas seus projetos serão compilados e testados automaticamente. Com uma 
quantidade de testes adequada para garantir que as funcionalidades existentes continuam 
funcionando e as novas vão funcionar, você pode ter versões sendo geradas todos os dias ou a 
cada commit! 
Nesse ponto, cruzamos com conceitos de TDD, Agile e outros. Mas é exatamente este o motivo pelo 
qual ferramentas de automação como o Maven são importantes. 
Espero que o leitor tenha compreendido seu funcionamento básico e possa evoluir daqui em diante 
para um melhor aproveitamento da automação em benefício da qualidade e da agilidade. 
 
 
 
 
Começando com o Gradle 
 
No artigo onde expliquei o que são Build Tools do Java, comentei sobre algumas ferramentas famosas, como 
é o caso do Ant, Maven e Gradle. Entretanto, não entrei em detalhes sobre o funcionamento delas. 
Sendo assim, neste artigo vou falar um pouco sobre como o Gradle funciona e como podemos usá-lo no 
nosso dia a dia. Bora começar? 
Sobre o Gradle 
Apenas para uma breve introdução, o Gradle trata-se de uma ferramenta de build open source bastante 
poderosa que nos permite configurar arquivos de build por meio da sua DSL (Domain Specific Language) 
baseada na linguagem Groovy. 
http://maven.apache.org/
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
http://maven.apache.org/guides/getting-started/index.html
https://medium.com/@alex.felipe?source=post_page-----4e96fd12d933--------------------------------
https://medium.com/@alex.felipe?source=post_page-----4e96fd12d933--------------------------------
https://medium.com/@alex.felipe/entenda-o-que-s%C3%A3o-build-tools-do-mundo-java-682a26e38ff2
https://github.com/gradle/gradle
http://groovy-lang.org/
“Então pra eu aprender Gradle eu preciso saber Groovy?” 
Não necessariamente, pois o motivo de escolherem uma linguagem dinâmica para a configuração é 
justamente para evitar a verbosidade da estrutura XML que é muito comum em ferramentas como essa. 
Claro, se você conhecer um pouco de Groovy vai tirar bastante proveito da syntax do código. 
Orientado a tasks 
Além da DSL, a ideia do Gradle é permitir configurações baseando-se em tasks, ou seja, quando queremos 
criar algum novo comportamento durante o build, vamos criar uma task! 
“Legal, mas como posso começar a configuração de build com Gradle?” 
Preparando o ambiente 
Antes de começar a falar da prática, sugiro que instale o Gradle para realizarmos alguns testes para facilitar a 
compreensão. 
Criando o primeiro arquivo de build 
Para darmos início em um projeto Gradle, primeiramente precisamos de um arquivo que tenha a 
extensão .gradle. 
Entretanto, por padrão, o Gradle busca por um arquivo chamado build.gradle, sendo assim, vamos criar 
o arquivo e abrí-lo com um editor. 
Eu costumo usar ou Visual Studio Code ou o IntelliJ (pode ser a versão Communty também) para esses 
testes devido ao syntax highlight. Tenho preferência pelo IntelliJ devivo ao auto complete ser mais 
eficiente. 
Declarando a primeira task 
Dentro do arquivo, vamos escrever o seguinte script: 
https://gradle.org/install/
task minhaPrimeiraTask { 
 print 'Rodando minha primeira task' 
} 
Repare que esse script trata-se de uma task que estamos criando. A ideia dela é de fato realizar um processo 
comum quando temos o primeiro contato, por exemplo, com uma linguagem de programação, ou seja, 
apresentar uma mensagem apenas. 
Portanto, com a nossa task declarada, dentro um terminal ou prompt de comando, vamos rodar o 
comando gradle minhaPrimeiraTask: 
 
 
Veja que nesse primeiro momento, o Gradle apresentou a mensagem Rodando minha primeira task da 
mesma maneira como colocamos no script, mas também, ele iniciou um processo chamado Gradle 
Daemon. O que isso significa? 
Entendendo o Gradle Daemon 
Basicamente, esse daemon trata-se de uma instância da JVM para o Gradle com a finalidade de agilizar a 
execução das tasks. Inclusive, podemos executar novamente a task para comprovar a ideia: 
 
 
Um detalhe bacana das tasks do Gradle é que não são case sensitive, por isso que conseguimos executar a 
task minhaPrimeiraTask escrevendo minhaprimeiratask 
Repare que agora o resultado foi bem diferente: 
• Não apareceu novamente a inicialização da Gradle Daemon, pois agora o daemon está de pé. 
• O tempo de execução foi de aproximadamente 3 para 0 segundos. 
Só que agora você deve estar se perguntando 
https://pt.wikipedia.org/wiki/Daemon_(computa%C3%A7%C3%A3o)
“Então esse processo vai ficar sem parar no meu computador?” 
Exatamente! Caso você queira saber o status dele, basta executar gradle --status: 
 
 
Repare que ele está apresentando 2 instâncias, pois eu já tinha parado a 4508. Caso queira parar a atual, é 
só executar o comando gradle --stop: 
 
 
Em outras palavras, por padrão, todas as vezes que utilizamos o Gradle ele vai executar um Gradle 
Daemon se não existir uma instância disponível. 
Claro, existe a possibilidade de desabilitar essa opção, e para mais detalhes deixo a referência da 
documentação. 
Conhecendo as tasks padrões do Gradle 
Fizemos o primeiro contato com o Gradle, entretanto, é muito comum termos a seguinte dúvida 
considerando o que vimos até agora: 
“Então quer dizer que vou ter que criar todas as tasks para o build?” 
Não necessariamente, pois, como é de se esperar, já existem diversas tasks disponíveis por padrão no Gradle. 
Para visualizá-las podemos executar gradle tasks: 
 
 
Repare que novamente subiu uma instância do Gradle Daemon, pois não tinha uma disponível. 
Observe que o Gradle fez uma lista bem grande de possíveis tasks que podem ser executadas no nosso 
projeto. Vamos entendê-las: 
https://docs.gradle.org/current/userguide/gradle_daemon.html
https://docs.gradle.org/current/userguide/gradle_daemon.html
• Build Setup: tasks para o processo de setup. 
• Help: tasks de ajuda de modo geral. 
De forma resumida, essa listagem apresentou 2 grupos de tasks, como também, a descrição de cada um 
deles. 
Entretanto, por listar todas as tasks possíveis para o nosso projeto, por que a nossa não apareceu? 
Listando todas as tasks, inclusive as nossas 
Como vimos, todas as tasks que foram apresentadas, fazem parte de um grupo e possuem uma descrição, 
certo? 
Em outras palavras, para que vejamos todas as tasks, mesmo que não façam parte de um grupo ou tenham 
uma descrição, basta apenas usar o parâmetro --all: 
 
 
 
Note que a nossa task aparece em um grupo chamado de Other tasks! Isto é, esse é o grupo padrão para 
todas as tasks que não possuem um grupo. 
“Bacana, mas como adicionamos um grupo e uma descrição para deixar a nossa task visível?” 
Adicionando grupo e descrição nas tasks 
Basicamente, precisamos adicionar o seguinte conteúdo no corpo da nossa task: 
task minhaPrimeiraTask { 
 group 'tasks pessoais' 
 description 'testes de primeiro contato com o Gradle' 
 print 'Rodando minha primeira task' 
} 
Então, após salvar o build.gradle, ao executar novamente a task tasks: 
 
 
 
Repare que agora aparece o nosso grupo Tasks pessoais, como também, a nossa task com a descrição que 
criamos! 
Muito bom! Aprendemos um pouco sobre tasks do Gradle, mas até o momento, não fomos capazes de criar 
um build que nos permita desenvolver um projetoem Java, certo? 
Em outras palavras, agora que entendemos o mínimo de como podemos criar uma task e como podemos 
visualizar todas as tasks disponíveis do projeto, daremos início num processo de build para construir uma 
aplicação Java. 
Criando um projeto Gradle inicial 
Como vimos, nas tasks disponíveis, temos a task init do grupo Build Setup que indica uma inicialização 
de um novo build do Gradle. 
De fato a ideia dessa task é permitir a criação de um projeto Gradle inicial com arquivos comuns. 
Portanto, antes de executar essa task, vamos criar um diretório para representar um projeto base que 
usaremos como exemplo. 
Nesse caso vou colocar o nome de ceep, pois trata-se de um projeto que estou usando como base para outros 
artigos que venho escrevendo de Kotlin 😅 
Então, dentro do diretório vamos executar o comando gradle init: 
 
 
 
A princípio, parece que não aconteceu nada demais, né? Entretanto, veja que o Gradle apresentou a 
mensagem 2 actionable tasks: 2 executed, isso significa que o Gradle executou duas tasks ao chamar a 
task init e podemos ver o resultado verificando a estrutura do diretório: 
 
 
 
 
Repare que além do build.gradle foram gerados outros arquivos e um diretório: 
https://medium.com/collabcode/criando-sua-primeira-aplica%C3%A7%C3%A3o-android-com-kotlin-695bb476d40b
https://medium.com/collabcode/criando-sua-primeira-aplica%C3%A7%C3%A3o-android-com-kotlin-695bb476d40b
• gradle: diretório que contém os arquivos do Gradle wrapper. 
• gradlew: Gradle wrapper para sistemas baseados em Unix (Linux). 
• gradlew.bat: Gradle wrapper para Windows. 
• settings.gradle: configurações do projeto. 
Como a ideia do artigo é apenas uma breve introdução, não daremos tanta atenção nos demais arquivos, ou 
seja, vamos verificar o conteúdo que foi gerado no arquivo build.gradle: 
Note que ele apresenta um comentário bem grande dando instruções de como podemos criar um sample de 
um projeto Java. De fato, se seguirmos as sugestões do Gradle, daremos o nosso primeiro passo no build de 
um projeto Java. 
Entretanto, repare que essa abordagem não parece tão objetiva, pois o Gradle criou um projeto inicial e 
ainda precisamos realizar mais configurações… 
Isso acontece, pois a task init, por padrão, assume um tipo de projeto conhecido como basic que o próprio 
nome já diz o que ele faz, isto é, gera um projeto básico. 
É justamente por esse motivo que o Gradle não gerou um projeto Java como esperado. 
Definindo o tipo do projeto como aplicação Java na inicialização 
Além do tipo basic, o Gradle nos fornece outros tipos de projetos, dentre eles temos o java-
application que tem o objetivo de gerar um projeto de uma aplicação Java, logo, vamos criar novamente o 
nosso projeto com a task init utilizando esse tipo. 
Entretanto, para que isso seja possível no mesmo diretório, precisamos remover tanto o arquivo os 
arquivos build.gradle e settings.gradle, pois eles são utilizados como base para indicar que existe um 
projeto do Gradle, ou seja, se eles estiverem presentes, a task init não cria um projeto novo. 
https://docs.gradle.org/current/userguide/build_init_plugin.html#sec:build_init_types
Após a remoção, execute o comando gradle init --type java-application: 
 
 
Observe que novamente duas tasks foram acionadas, porém, apenas uma delas foi executada e a outra está 
indicando que foi atualizada (up-to-date). 
“O que isso significa?” 
Uma breve introdução à construção incremental 
Uma das grandes vantagens ao utilizar o Gradle, é justamente a ideia do incremental build, isto é, o Gradle 
“não executa tasks que já foram executada”. 
Lembra que quando executamos a tasks init pela primeira vez, foram executadas 2 tasks? Uma dessas 
tasks era responsável em gerar os arquivos de wrapper, porém, não removemos nenhum deles. 
Justamente por esse motivo, o Gradle não viu a necessidade de executar essa task! Incrível, né? 
Esse é um assunto que pode levar bastante tempo, por isso não vou me aprofundar, porém, se tiver alguma 
dúvida, fique à vontade em perguntar. 
Entendendo os arquivos gerados para aplicação Java 
Legal, vamos verificar o que foi gerado em um projeto do tipo java-application: 
 
 
Repare que agora, além dos arquivos do Gradle que vimos anteriormente, temos também o 
diretório src (também conhecido como source set) que contém uma estrutura bem similar ao padrão que 
vemos em projetos Maven: 
• main/java: código fonte para desenvolvimento. 
• test/java: código fonte para testes. 
https://guides.gradle.org/performance/
Inclusive, o Gradle já gerou alguns arquivos Java pra gente, vamos dar uma olhada em cada um deles: 
Veja que trata-se de classes de exemplo para testarmos o nosso projeto. Aproveitando vamos dar uma olhada 
no conteúdo que foi gerado do arquivo build.gradle: 
Veja que dessa vez, além dos comentários, o Gradle já adicionou alguns plugins, repositórios, dependências e 
definiu uma main class… 
Em outras palavras, o próprio Gradle já fez toda a estrutura que é comum em um projeto Java pra gente! 
Portanto, o que nos resta é apenas testar e verificar o comportamento desse projeto. Mas como podemos 
fazer isso? 
Verificando as tasks do projeto Java 
Agora que estamos nesse projeto com toda essa configuração, vamos verificar as tasks disponíveis para ele: 
 
 
 
Wow! Olha o tanto de tasks que temos disponíveis com a configuração do nosso projeto atual. Isso significa 
que temos diversas ações que podemos aplicar nesse projeto. 
Rodando o projeto 
A primeira delas é justamente a run que indica a execução do projeto, vamos rodá-la e ver o que acontece: 
 
 
Inicialmente o Gradle verificou que eu não tinha a dependência do Guava e por isso a baixou primeiro. 
Depois de finalizar o download e realizar outras tasks (como a de compilação), ela executou a task run, que 
por sua vez, executou a classe App, justamente por esse motivo do download (internet boa… Sacomé 😁) que 
o processo num todo demorou aproximadamente 17 segundos. 
Sendo assim, vamos verificar o que acontece ao executar a task run novamente: 
 
 
Bem mais rápido, né? Mais incrível ainda, é quando verificamos a estrutura de arquivos do nosso projeto: 
 
 
Veja que agora surgiu o diretório build que mantém de todos os arquivos compilados, ou seja, para que a 
classe App fosse executada, foi necessário criar o .class dela e o Gradle já fez tudo isso pra gente! 
Para saber mais 
Vimos bastante conteúdo sobre o que é o Gradle e como podemos utilizá-lo de maneira inicial usando apenas 
o command line. 
Entretanto, a ideia do Gradle não é fazer com que a gente desenvolva aplicações em editores quaisquer e 
realizando o processo de build via command line. 
Ou seja, com esse projeto gerado, o próximo passo é importá-lo em uma IDE que dê suporte ao Gradle, como 
é o caso do IntelliJ IDEA que já vem com o plugin do Gradle instalado. 
É possível também usar no Eclipse e no NetBeans, porém, vai precisar baixar o plugin a 
parte. 
Dessa forma, ao invés do projeto ser gerenciado por uma IDE, ele é gerenciado pelo Gradle fortalecendo a 
ideia de compatibilidade independentemente da IDE. 
Conclusão 
Neste artigo tivemos o nosso primeiro contato com o Gradle e aprendemos das features e peculiaridades da 
ferramenta, como por exemplo, como começar um build, a instância do Gradle Daemon, execução de tasks, 
listagem de tasks e a criação de um projeto para dar suporte a aplicações Java. 
 
 
Usando cmake para compilar c/c++ 
Como usar o cmake para compilar projetos em c/c++ 
 
CMake — Cross-Platform Makefile Generator 
O que é o cmake 
O CMake é um "Cross-Platform Makefile Generator" ou uma ferramenta open-source que permite gerar 
automaticamente scripts de construção de aplicação em diferentes plataformas, como por exemplo "Unix 
Makefiles, Xcode, Visual Studio, CodeBlocks etc …", uma lista completa pode ser encontrada aqui. 
Instalando o cmake 
Para instalar o cmake abra o terminal e siga as instruções abaixo.# For Ubuntu 
$ sudo apt-get install cmake# For Redhat 
$ yum install cmake# For Mac OS X with brew 
$ brew install cmake 
Criando um hello world em cpp 
Para facilitar nosso exemplo vamos criar um pequeno hello world em cpp e gerar o build com o cmake. 
Criando um diretório para o projeto. 
• $ mkdir sampleCmake 
• $ cd sampleCmake 
• $ vi main.cpp 
Dentro do arquivo main.cpp coloque o conteúdo abaixo. 
#include <iostream> 
 
using namespace std; 
 
int main(void) { 
 
https://cmake.org/cmake/help/v2.8.10/cmake.html#gen:BorlandMakefiles
 cout << "Hello World" << endl; 
 
 return(0); 
 
} 
Agora temos que criar o nosso CMakeLists.txt que será o roteiro usado pelo cmake para criar os scripts de 
compilação da aplicação. dentro do CMakeLists.txt coloque o conteúdo listado abaixo. 
cmake_minimum_required(VERSION 2.8) 
project(sampleCmake) 
add_executable(hello main.cpp) 
Uma vez criado os arquivos do nosso projeto vamos testar para saber se está tudo funcionando como 
planejado para isso siga as instruções abaixo. 
$ mkdir build && cd build 
$ cmake ../ 
$ make 
$ ./hello 
Nos criamos um diretório aparte para compilar o projeto convencionalmente chamado de build e depois 
executamos o cmake ../ mas informações para que ele procure o CMakeLists.txt no diretório anterior. Uma 
vez que encontre o CMakeLists.txt o cmake começa a construção dos scripts de compilação necessários no 
caso do exemplo acima um Makefile. Terminado a construção sem erros temos um arquivo Makefile pronto 
para compilação nesse caso é só executar um "make" para compilar e depois executar o binário "./hello". 
Melhorando um pouco nosso projeto. 
Agora digamos que eu queira controlar a versão do meu binário, com o cmake também podemos fazer essa 
tarefa de forma simples segue abaixo algumas alterações que teremos que fazer no nosso projeto. 
Altere o arquivo CMakeLists.txt conforme abaixo : 
cmake_minimum_required(VERSION 2.8) 
project(sampleCmake)set (Sample_VERSION_MAJOR 0) 
set (Sample_VERSION_MINOR 0) 
set (Sample_VERSION_PATCH 1)configure_file( 
 "${PROJECT_SOURCE_DIR}/SampleConfig.h.in" 
 "${PROJECT_BINARY_DIR}/SampleConfig.h" 
 )include_directories("${PROJECT_BINARY_DIR}")add_executable(hello main.cpp) 
Crie o arquivo chamado "SampleConfig.h.in" com o conteúdo listado abaixo. 
#define SAMPLE_VERSION_MAJOR @Sample_VERSION_MAJOR@ 
#define SAMPLE_VERSION_MINOR @Sample_VERSION_MINOR@ 
#define SAMPLE_VERSION_PATCH @Sample_VERSION_PATCH@ 
Agora altere o arquivo main.cpp para ficar como o conteúdo listado abaixo. 
#include <iostream> 
#include "SampleConfig.h"void version() 
{ 
 std::cout << "Version : " << SAMPLE_VERSION_MAJOR << 
 "." << SAMPLE_VERSION_MINOR << 
 "." << SAMPLE_VERSION_PATCH << std::endl; 
}int 
main(void) 
{ 
 version(); 
 std::cout << "Hello World by CMake !!!" << std::endl; 
 return(0); 
} 
Uma vez feitas estas alterações compile novamente o projeto usando o cmake conforme descrito 
anteriormente. 
$ rm -rf build 
$ mkdir build && cd build 
$ cmake ../ 
$ make 
$ ./hello 
Version : 0.0.1 
Hello World by CMake !!! 
O resultado deve ser uma saída como mostrado acima. Com o cmake podemos fazer muito mais no próximo 
artigo vou mostrar como usar o cmake para compilar um projeto usando biblioteca de terceiros como a 
libcurl. 
 
 
PERGUNTA 1 
Questão referente a: 
• Texto-base 1 - Instalando, configurando e usando o Maven para gerenciar suas dependências e seus 
projetos Java 
• Texto-base 2: Começando com o Gradle 
• Texto-base 3: Usando CMake para compilar c/c++ 
Qual(is) das ferramentas de automação de compilação apresentadas usa(m) como base um arquivo escrito 
em linguagem específica de domínio (DSL)? 
o Maven e Gradle. 
 
o Gradle. 
o CMake. 
o Maven. 
o Gradle, Maven e CMake. 
 
Você acertou! Essa é a alternativa correta. Apenas Gradle usa como base um arquivo escrito em linguagem 
específica de domínio (DSL), baseada em Groovy. 
http://twitter.com/Sample_VERSION_MAJOR
http://twitter.com/Sample_VERSION_MINOR
http://twitter.com/Sample_VERSION_PATCH
ATIV IDADE AVALIATIVA 
 
PERGUNTA 1 
Para que é usado o método fail() do JUnit? 
o Para fazer com que o teste seja depurado. 
o Para fazer com que o testador busque o erro. 
o Para fazer com que o erro seja encontrado. 
o Para fazer com que o programador seja penalizado. 
o Para fazer com que o teste falhe. 
 
PERGUNTA 2 
Marque a alternativa que apresenta apenas anotações existentes no JUnit 4.x para serem usados em classes de 
teste: 
o @After, @AfterClass, @Before, @BeforeClass, @Test. 
 
o @AfterClass, @Before, @BeforeClass, @During, @Test. 
o @After, @AfterClass, @BeforeClass, @During, @Test. 
 
o @After, @Before, @BeforeClass, @During, @Test. 
 
o @After, @AfterClass, @Before, @BeforeClass, @During. 
 
PERGUNTA 3 
Qual alternativa apresenta a ordem correta dos itens usados para definir exemplos concretos de comportamento 
seguindo BDD? 
o Dado > Cenário > Então > Quando. 
o Cenário > Dado > Então > Quando. 
o Cenário > Quando > Dado > Então. 
o Cenário > Dado > Quando > Então. 
o Dado > Cenário > Quando > Então. 
 
PERGUNTA 4 
Marque a alternativa que apresenta um exemplo de comando da ferramenta Selenium IDE: 
o ClickAndGo. 
o WaitAndType. 
o WaitTo. 
o Assert. 
o Validate. 
 
PERGUNTA 5 
Qual alternativa abaixo apresenta uma característica correta da ferramenta Selenium IDE? 
o Pode exportar para scripts do WebDriver. 
 
o Pode fornecer um relatório de teste detalhado. 
o Permite editar os scripts pré-gravados. 
o Pode realizar testes de banco de dados. 
o Suporta testes orientados a dados.