Há alguns meses tive o privilégio de assistir à uma sessão de palestras de um dos meus autores favoritos: Martin Fowler. O tema era sobre padrões arquiteturais para desenvolvimento, distribuição e operação de aplicações, alguns pouco conhecidos, mas muito úteis.
Vou escrever uma série de 3 artigos falando sobre alguns dos padrões que considero mais interessantes. Vamos ao primeiro!
Meu trabalho na Atlassian envolve primariamente o desempenho do JIRA na nuvem. Descrevi parte do meu trabalho no artigo Hello, JIRA, mas existem muitos detalhes complexos que acabam ficando de fora.
Neste artigo vou descrever brevemente um importante aspecto sobre desempenho de grandes aplicações web e indicar um vídeo que explica o assunto do ponto de vista do Facebook em maiores detalhes.
Há 7 anos ouvi pela primeira vez o termo Arquiteto de Software numa feira sobre Java promovida pela Global Code em São Paulo. E surgiu a pergunta ao final de uma das palestras:
Quanto tempo leva para se tornar um arquiteto de software?
Coçando o queixo, o palestrante exitou alguns segundos e então lançou:
Com uns 5 anos e muita dedicação é possível formar um arquiteto.
Desde então, como alguém que respira TI, comecei a perseguir o tão famigerado título.
Há muitas definições. Algumas você pode encontrar na Wikipédia, na InfoQ, no Blog da GlobalCode, no fórum Javafree.
Não só a definição formal varia, como há muitas visões diferentes sobre a real necessidade deste tipo de profissional.
Não quero repetir aqui o que já existe em dezenas de sites. Então vou resumir em poucas palavras a minha opinião:
Arquiteto de Software é o especialista técnico que enxerga mais longe e mais profundamente, podendo orientar e participar das decisões tecnológicas.
Existe um estereótipo de arquiteto análogo ao Arquiteto do filme Matrix, isto é, que fica escondido em uma sala tomando todas as decisões importantes e impondo-as aos meros programadores que não podem pensar por si mesmos.
Em termos gerais, deploy significa colocar em posição. Na prática, geralmente falamos de disponibilizar um sistema para uso, seja num ambiente de desenvolvimento, para testes ou em produção.
O termo deploy pode significar muitas coisas, dependendo do ambiente e da tecnologia. Um desenvolvedor pode fazer o deploy da aplicação web no seu Tomcat local. Pode também fazer o deploy no Weblogic em produção, usado pelos usuários finais.
I’m pleased to announce the first stable release of Jericho Selector.
Jericho Selector is an extension to the known library Jericho HTML Parser that allows you to select elements from an HTML document just like you do with jQuery, using CSS selectors.
Why Jericho? Different from jsoup, it allows you to modify the document keeping the original formatting. Other libraries rewrite the entire document. Anyway, I like to have a choice! 😉
Jericho Selector is completely free. It uses MIT license.
Jericho Selector is available at Maven Central Repository, so you just need to add the following dependency to your project:
<dependency>
<groupId>br.com.starcode.jerichoselector</groupId>
<artifactId>jericho-selector</artifactId>
<version>1.0.1-RELEASE</version>
</dependency>
Import the static method $ that is the entry point for Jericho Selector:
import static br.com.starcode.jerichoselector.jerQuery.$;
Then you can query HTML elements just like jQuery:
$(html, "p.my-text")
Before implementing Jericho Selector, I had to implement a full CSS parser. In order to do that, I created another library called parCCSer. It was based on the official W3C CSS3 specification and covers almot all of the specification, except some details that are valid only in the context of a browser and also something related to UTF-8 support that I considered not entirely necessary. It’s also under MIT license.
Jericho Selector then uses the object tree generated by parCCser, as the Jericho HTML Parser API, to query the HTML document elements given a CSS selector.
All implementitions are covered by unit testes above 90%, without taking in account excepcional cases that the plugin are not able to analyse.
In the next weeks I aim to add some fluent API features to Jericho Selector, similar to jQuery, so you can make some operations using lambdas, for example. Methods like closest, parentsUntil, find, each are my priorities.
Another point to improve is the performance. Specific selectors can be optimized using cache or specific Jericho HTML Parser methods like getAllElementsByClass.
Report any problem and suggest new features!
You can get check out the source code from GitHub account:
É com grande satisfação que venho anunciar a publicação da primeira versão estável (stable release) da biblioteca Jericho Selector.
O Jericho Selector é uma extensão para a conhecida biblioteca de leitura e manipulação de HTML Jericho HTML Parser que permite selecionar elementos de um documento HTML ao estilo do jQuery, ou seja, utilizando seletores CSS.
Por quê Jericho? Diferente do jsoup, por exemplo, ele permite alterar documents HTML mantendo a formatação original. Outras bibliotecas reescrevem o documento inteiro. De qualquer forma, eu gosto de ter opções! 😉
Jericho Selector é totalmente livre, sob a licença MIT.
O Jericho Selector está disponível no Repositório Central do Maven, então basta configurar o seu projeto com a seguinte dependência:
<dependency>
<groupId>br.com.starcode.jerichoselector</groupId>
<artifactId>jericho-selector</artifactId>
<version>1.0.1-RELEASE</version>
</dependency>
Depois, faça a importação do método estático $ que pode ser usado como ponto de entrada para uso do Jericho Selector:
import static br.com.starcode.jerichoselector.jerQuery.$;
Então você poderá realizar consultas da seguinte forma:
$(html, "p.my-text")
Antes de iniciar a implementação do Jericho Selector, tive que implementar um interpretador (parser) completo de seletores CSS. Para isso, implementei outra biblioteca que chamei de parCCSer. Ela foi baseada na especificação oficial do W3C para CSS3 e cobre praticamente todos os aspectos da especificação, exceto alguns detalhes que se aplicariam apenas no contexto de um navegador e também algo relacionado a suporte de caracteres UTF-8. Ela também está sob a licença MIT.
O Jericho Selector então utiliza a árvore de objetos gerada pelo parCCser, assim como a API do Jericho HTML Parser para consultar os elementos de um documento HTML com base em um dado seletor.
Todas as implementações possuem cobertura em testes unitários de mais de 90% do código, sem contar os casos excepcionais que o plugin de cobertura não consegue analisar.
Nas próximas semanas pretendo adicionar ao Jericho Selector funcionalidades de uma API fluente, análogas ao jQuery, para que seja possível realizar operações com os elementos recuperados usando lambdas e outros recursos. Métodos como closest, parentsUntil, find, each são meus primeiros alvos.
Outro ponto a melhorar é o desempenho da biblioteca. Alguns seletores específicos podem ter sua execução otimizada utilizando cache ou métodos específicos do Jericho HTML Parser como getAllElementsByClass.
Reporte qualquer problema e sugira novas funcionalidades!
Confira o código e maiores detalhes na minha página do GitHub:
Domain-Driven Design ou Projeto Orientado ao Domínio é um padrão de modelagem de software orientado a objetos que procura reforçar conceitos e boas práticas relacionadas à Orientação a Objetos.
Isso vem em contrapartida ao uso comum do Data-Driven Design ou Projeto Orientado a Dados, que a maioria dos desenvolvedores usa sem mesmo ter consciência disso.
Já ouvi várias vezes que os dados são a coisa mais importante em uma empresa, logo a modelagem deve sempre começar pensando-se no banco de dados. Esta é a abordagem algumas vezes chamada de database first, ou “banco de dados em primeiro lugar”.
Não é nada incomum desenvolvedores .Net, Java e C++ começarem um sistema estabelecendo os tipos que eles vão usar e o relacionamento entre eles, como se estivessem criando um Modelo Entidade-Relacionamento (MER). Esses tipos geralmente são objetos “burros”, com getters e setters, representando nada mais, nada menos, que uma tabela do banco de dados.
O problema com essa abordagem é que ela não faz bom uso dos recursos da Orientação a Objetos. Muitos acham que getters e setters são o auge do encapsulamento, mas na prática esses métodos permitem ao usuário recuperar e alterar todos os atributos. Não há ganho algum, a não ser muito código desnecessário.
Enfim, muita gente acha que está usando OO, mas as classes poderiam ser facilmente substituídas por registros ou estruturas de dados mais simples, de acordo com a linguagem utilizada.
Se você consegue ler em Inglês, uma discussão interessante sobre isso está no artigo Dance you Imps!, escrito por Rebert Martin e também conhecido como Uncle Bob.
A ideia inicial do DDD é voltar à uma modelagem OO mais pura, por assim dizer.
Devemos esquecer de como os dados são persistidos e nos preocupar em como representar melhor as necessidades de negócio em classes e comportamentos (métodos). Esta é uma abordam também conhecida como como code first, ou “código em primeiro lugar”.
Isso significa que em DDD um Cliente pode não ter um setter para os seus atributos comuns, mas pode ter métodos com lógica de negócio que neste domínio de negócio pertencem ao cliente, como void associarNovoCartao(Cartao) ou Conta recuperarInformacoesConta().
Em resumo, as classes modeladas e os seus métodos deveriam representar o negócio da empresa, usando inclusive a mesma nomenclatura. A persistência dos dados é colocada em segundo plano, sendo apenas uma camada complementar.
DDD não é uma solução para tudo. A maioria dos sistemas possui uma boa parte composta por cadastros básicos (CRUD) e pelo menos nessa parte não há necessidade de um modelo elaborado de dados.
O DDD deve ajudar na modelagem das classes mais importantes e mais centrais do sistema de forma e diminuir a complexidade e ajudar na manutenção das mesmas, afinal este é o objetivo dos princípios de orientação a objetos.
Rotinas de integração que recebem ou disponibilizam dados para outros sistemas não devem ser “inteligentes”.
Muitos desenvolvedores acabam modelando suas classes de negócios tentando resolver as questões internas do sistema e, ao mesmo tempo, pensando em como essas classes serão expostas para outros sistemas.
Padrões como DTO (Data Transfer Object) que usam objetos “burros” são mais adequados para isso.
O DDD não tenta resolver todos os problemas de todas as camadas de um sistema.
Seu foco é na modelagem das entidades principais de negócio usando a linguagem adequada daquele domínio para facilitar a manutenção, extensão e entendimento.
Particularmente, eu não seguiria à risca o padrão, até porque existem inúmeros padrões e variações de modelagem OO.
Porém, é sempre importante estudar e entender os princípios por detrás desses padrões para, dessa forma, aplicar o que funciona melhor para cada situação.
Nota: escrevi termos como domain-driven com hífen, pois quando duas ou mais palavras formam um adjetivo composto no Inglês elas geralmente devem ser “ligadas”. No caso, domain-driven é um adjetivo de design. (Referência)
Frameworks Component Based mantém sincronia entre os estados dos componentes da view e do seu modelo de dados no lado do servidor.
Quando o usuário interage com a tela, as alterações realizadas são, em um dado momento, refletidas no modelo que fica no servidor.
No JSF, por exemplo, a “tela” é gerada por um facelet, que nada mais é que um XML que define quais componentes serão exibidos para o usuário e associam os valores desses componentes a um objeto (Java Bean) que fica no servidor. Esses componentes são então renderizados em HTML e, quando o usuário executa uma ação, o JSF atualiza os objetos no servidor.
Não encontrei uma representação visual adequada, mas algo aproximado num artigo da Caelum sobre o tema:
Component Based Request
Em frameworks component based, a view é responsável por mapear valores para os beans e para o modelo. A imagem acima ilustra a ordem de chamadas:
Já os frameworks Action Based não mantém necessariamente esse vínculo entre os estados do servidor e do cliente.
Isso não quer dizer que o desenvolvedor não possa armazenar estado no servidor, por exemplo, na sessão do usuário, mas que o vínculo entre o modelo e a view não é tão acoplado como no modelo Component Based.
Um framework Action Based geralmente irá receber diretamente requisições HTTP. Isso torna o modelo action based mais flexível, já que o desenvolvedor pode optar por qualquer tipo de view que gere uma requisição HTTP compatível.
Considere a ilustração a seguir (da mesma fonte anterior):
Action Based Request
O resumo dos passos da execução é:
Podemos dizer que os frameworks component based são mais centrados nas views (com seus componentes que mapeiam o modelo e os dados do usuário), enquanto os action based são mais centrados nos controllers (que recebem parâmetros via request).
Este artigo é baseado na minha resposta do Stack Overflow em Português
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:
O Maven é uma ferramenta de gerenciamento de dependências e do ciclo de vida de projetos de software no sentido técnico. Isso inclui:
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:
br.com.starcode, org.apache, com.google, com.ibm, etc.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.jdk4 e jdk6. Se há variações específicas para Sistemas Operacionais, podemos ter os classificadores linux e windows.É 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.
Consiste numa aplicação que disponibiliza artefatos do Maven. Pode se 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.
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.
Há um arquivo pom por projeto, mas ele pode herdar configurações de um parent pom, isto é, como se houvesse um projeto "pai".
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.
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.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.
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.
A adoção do Maven no desenvolvimento traz de imediato os seguintes benefícios:
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.
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.
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, podem 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.
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.
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.
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:
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.
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.
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:
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:
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:
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.
É 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>
<host>proxy.intranet.empresa.com</host>
<port>8080</port>
<nonProxyHosts>localhost,127.*,192.*</nonProxyHosts>
</proxy>
</proxies>
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.
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....
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....
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.
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.
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.
Vá até o menu User Settings. Há um warning lá dizendo que a configuração do usuário não existe. Você pode criar um 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.
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.
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.
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:
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:
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/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-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>
</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"));
}
}
Executei o método main clicando com o botão direito sobre a classe, menu Run As > Java Application. Veja o resultado:
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, somente exibido)
* @return Texto sem posíveis tags HTML
*/
public static String escapeHTML(String html) {
return StringEscapeUtils.escapeHtml4(html);
}
}
Veja no Eclipse:
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/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-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.
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 = "<script>alert(1);</script>";
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:
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:
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.
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:
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.
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:
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:
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 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.
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.
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.
Usar o Maven para desenvolver projetos pessoais é relativamente fácil e 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:
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.
Continuando a série de artigos sobre configuração de um ambiente de desenvolvimento no linux Ubuntu em uma máquina virtual, chegou a hora do Eclipse.
Você deve ter o JDK instalado no seu Ubuntu. Os passos de instalação do Ubuntu e do Java estão em seus respectivos artigos:
Acesse a página de download do Eclipse a partir do seu Ubuntu. Vamos fazer o download da versão Eclipse IDE for Java EE Developers, que já vem com um conjunto maior de plugins do que a versão Standard.
Meu Ubuntu é de 64 bits, portanto vou selecionar a opção Linux 64 Bit, conforme indicado na imagem:
Na próxima tela, clique na seta verde para iniciar o download.
Salve o arquivo no local desejado e aguarde o término do download.
Ainda no navegador, clique sobre o nome do arquivo para abri-lo, conforme a imagem abaixo. Ou simplesmente abra o gerenciador de arquivos e navegue até o diretório onde baixou o arquivo e abra-o com um duplo clique. O arquivo deve ter sido baixado no diretório ~/Downloads, que é a pasta padrão de downloads do usuário.
Agora, o arquivo deve estar aberto no Archive Manager, conforme a imagem:
Selecione a pasta eclipse que aparece na listagem do programa e clique no botão Extract da barra de ferramentas.
A caixa de diálogo de extração aparecerá. Navegue até um diretório de sua preferência para descompactar o Eclipse. Se estiver em dúvida ou tiver problemas de permissão, use o diretório Home (~), como na imagem.
Clique no botão Extract para confirmar a extração.
Após a conclusão, o Archive Manager mostratá um diálogo. Clique em Show the Files para abrir o diretório Home. Acesse a pasta eclipse com um clique duplo.
Você deve estar vendo os arquivos do Eclipse, incluindo o executável dele.
Ao invés de abri-lo, vamos criar um atalho para facilitar nas demais utilizações. Clique com o botão direito sobre o executável e selecione a opção Make Link.
Um atalho deve ter sido criado como na imagem abaixo:
Com o atalho selecionado, pressione CTRL+X para recortá-lo.
Minimize todas as janelas, clique com o botão direito no fundo da sua Área de Trabalho e selecione a opção Paste.
Pronto!
Antes de iniciar o Eclipse, vamos ajustar alguns parâmetro de memória para melhorar o desempenho geral de nossa IDE.
Primeiro, abra o explorador de arquivos e vá até o diretório onde extraiu os arquivos do Eclipse. No nosso caso é ~/eclipse.
Clique com o botão direito sobre o arquivo eclipse.ini e abra com um editor de texto. Você verá o arquivo com o conteúdo a seguir:
Vamos aumentar um pouco os parâmetros de memória:
O conteúdo do arquivo ficou assim:
-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20140116-2212
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XX:MaxPermSize=256m
-Xms512m
-Xmx1G
Feche o editor e não esqueça de salvar o arquivo.
Clique duas vezes sobre o ícone que criamos na área de trabalho. A splash screen irá aparecer.
Aguarde e logo você será saudado pelo Workspace Launcher para selecionar o Workspace de trabalho.
Clique em OK para criar um novo Workspace no diretório indicado. Aguarde mais um pouco para ver a tela de boas-vindas.
Clique no link Workbench para fechar a tela de abertura e ir à perspectiva de desenvolvimento.
Agora é só usar!
Caso não esteja acostumado com o Eclipse, não deixe de ler o artigo Instalando, Configurando e Usando o Eclipse Kepler.
Embora o tutorial seja para instalação no Windows, na segunda parte você encontra detalhes sobre como realizar configurações básicas, criar um projeto, executar e depurar um programa, além de informações sobre os componentes principais do Eclipse.
Com Java e o Eclipse instalados no linux, você já tem um ambiente para iniciar o desenvolvimento de aplicações.
Pretendo em artigos futuros usar este ambiente para ilustrar o desenvolvimento de aplicações Big Data com Hadoop.
Acompanhe minhas respostas no Stack Overflow em Português.
O blog State of the Art de Luiz Ricardo é licenciado sob uma Licença Creative Commons. Copie, compartihe e modifique, apenas cite a fonte.