MAVEN 2

Há alguns anos, a Apache Software Fundation (ASF) criou uma ferramenta utilizada para automatizar a construção de software em java. Essa ferramenta utiliza um arquivo no formato xml para descrever o processo de construção e suas dependências. Por padrão, este arquivo xml tem o nome build.xml. A forma como estes arquivos de devem ser configurados dificulta a sua utilização por usuários novatos e para grandes projetos onde estes arquivos podem se tornar grandes e complexos. Além disso, o ANT acabou não atendendo a um dos seus propósitos que era criar uma padronização para os projetos da ASF. Foi aí então que a Fundação desenvolveu outra ferramenta com uma visão de mais alto nível na construção de sistemas, o MAVEN. Posteriormente, o MAVEN foi completamente reescrito dando origem ao MAVEN 2.

Assim como o ANT, o Maven centraliza todas as informações do projeto em um único arquivo xml, porém, de uma forma declarativa e muito mais simples. Neste caso, por padrão, o aquivo tem o nome pom.xm (Project Object Model) e nele são definidos dados como: nome do projeto, informações dos desenvolvedores, dados do repositório e sistema de controle de versão, dependências de bibliotecas externas, entre outros.

O Maven gerencia projetos desde a sua criação (com a geração do esqueleto inicial do sistema) até a sua implantação em um servidor (remoto ou não). Além disso, o Maven é uma ferramenta que prega a padronização dos projetos para permitir que um desenvolvedor que conhece a estrutura de um projeto básico do Maven, não terá problemas para entender outro projeto que siga a mesma estrutura. Dessa forma, diminuindo de forma significativa o tempo que o desenvolvedor vai levar para assimilar um novo sistema.

Outra premissa seguida pelo Maven é a “convenção sobre configuração”. Seguindo-se um padrão pré-estabelecido, não é necessário dizer ao Maven que você está fazendo isso. Como exemplo, o Maven define um padrão para a estrutura de diretórios no seu projeto e, se for seguido, não será necessário informar ao plugin do compilador Javac onde ficam os seus arquivos de código fonte nem pra onde ele deve copiar os arquivos “.class” resultantes, pois ele já sabe exatamente onde procurar por tudo.

Motivação

A seguir, será apresentada uma adaptação do artigo de Pacheco (2009) onde são apresentados dez motivos para utilização do Maven:

  1. Simplicidade : Com o Maven temos uma solução de gerência de configurações. De forma que o desenvolvedor, com um único comando do Maven, baixa as dependências necessárias, roda os testes, configura o ambiente, baixa o servidor de aplicação, faz o deploy e abre o browser com a tela de login do sistema.
  2. Automatização : Com o Maven você atinge rapidamente um nível de automatização muito alto e com pouquíssima configuração. Essa automatização se reflete no processo de release de um versão do seu software que fica muito mais simples com o Maven.
  3. Foco na Qualidade : O Maven incentiva que se criem testes unitários. De forma que quando você faz o build ou gera um deploy em um servidor, ele roda todos os testes unitários. Caso algum teste unitário falhe, ele aborda o build/deploy. Essa é uma excelente política para forçar os testes e a qualidade de software.
  4. Ciclo de Vida : Diferente do ant, o Maven tem todo um ciclo de vida definido. Assim, à medida que algo vai acontecendo e ele vai mudando de estados no ciclo de vida, determinados plugins (goals) serão executados. Você pode parametrizar o que você quer que aconteça em cada momento do ciclo de vida do Maven.
  5. Contexto e Informações : Com o Maven é possível ter de forma contextualizada as informações úteis do projeto. Ele pode gerar um site contendo:
    – Lista de Desenvolvedores
    – Links para o controle de versão
    – Links para o sistema de build contínuo
    – Links para o sistema de issue tracking
    – Lista de discussão
    – Dependências do projeto
    – Resultado da execução dos testes
    – Javadoc e documentação
  6. Consistência : No Maven tudo é igual, você faz todas as parametrizações através do arquivo pom.xml e tudo da mesma forma. O que se faz em um projeto pode ser aproveitado efetivamente em outro sem a necessidade de copiar e colar.
  7. Gerência de Dependências : Quando usamos muitos frameworks em Java através de vários projetos, gerenciar esses artefatos e controlar as suas versões torna-se muito difícil. O Maven provê a gerência de jar, bem como de plugins. Esses artefatos não ficam no controlador de versão. Ao invés de criarmos uma pasta lib e incluir os jars nela, eles ficam no repositório local do Maven.
  8. Plugins : No Maven tudo são plugins. O próprio core do Maven é feito de plugins, que vão desde o que faz o clean ao que gera o Javadoc ou o que gera estatísticas da qualidade do seu projeto. Além de existirem muitos plugins para o Maven, ainda podemos criar o nosso próprio.
  9. Cascateamento : Outra grande característica do Maven é o cascateamento de configurações. Graças a sua estrutura de hierarquias de POM. Desta forma não é necessário duplicar configurações e todo o projeto filho de um POM herda todas as suas configurações. Com isso é possível fazer um balanceamento de configurações.
  10. Build Modular : O Maven vai fazer o build do seu projeto utilizando o conceito de convenção sobre configuração. Logo, se os artefatos forem colocados nas estruturas padrão do Maven, não será necessário configurar várias coisas que se configuraria com ANT, como o diretório de fontes, os recursos e para onde será gerado os binários. No Maven os projetos são estruturados de forma modular. Quando fazemos o build no “pai”, ele faz o build para cada “filho”. Assim, não precisamos recompilar todos os módulos, ou quando queremos isso, não precisamos fazer um a um.

Instalação do Maven 2

Para instalar o Maven 2 utilizando Ubuntu basta digitar o seguinte comando no console:

sudo apt-get install maven2

Alternativamente, podemos instalar o Maven a partir do download no site http://maven.apache.org/download.html. Em seguida, descompactar o arquivo e adicionar algumas variáveis de ambiente. No caso do ubuntu, adicione as linhas a seguir no arquivo /etc/profile:

export M2_HOME=/caminho_para/apache-maven
export PATH=$M2_HOME/bin:$PATH

Para verificar se a instalação está correta digite o comando mvn -v no seu terminal e deverá ver um resultado similar ao apresentado a seguir:

Apache Maven 2.2.1 (r801777; 2009-08-06 16:16:01-0300)
Java version: 1.6.0_06
Java home: /home/siep/jdk
Default locale: pt_BR, platform encoding: UTF-8
OS name: "linux" version: "2.6.24-21-generic" arch: "i386" Family: "unix"

Ao instalar o maven2, ele cria um repositório em sua máquina que pode ser acessado através do comando:

cd ~/.m2/repository

Neste repositório são colocadas todas as bibliotecas que declararamos nos pom.xml das nossas aplicações. Por este motivo, as aplicações ficam minúsculas no controle de versão, já que as bibliotecas estão centralizadas no maven e não precisam mais acompanhar os fontes dos projetos. Toda vez que for compilar a aplicação, o Maven executa o download daquelas libs declaradas que não constam no repositório local e, por isso, se baixarmos os fontes do projeto em outra máquina, basta instalar o maven e ele resolverá todas as dependências.

O Arquivo de Configuração POM (pom.xml)

O primeiro passo a ser seguido na concepção de um projeto utilizando o Maven 2 é a definição do seu arquivo de configuração, o POM. É nesse arquivo que são definidas algumas informações necessárias pelo Maven durante o processo de “build”. Seguindo a estrutura de diretórios e arquivos padrão, esse arquivo tem que estar na pasta raiz do projeto e deve se chamar “pom.xml”. A seguir, é mostrado a estrutura básica de um POM e sua descrição:

<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/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>br.siep</groupId>
  <artifactId>atualizador</artifactId>
  <packaging>war</packaging>
  <version>2.0.0</version>
  <name>Modulo Atualizador</name>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>
Descrição
<modelVersion>4.0.0</modelVersion> É um nó obrigatório e contém a versão do arquivo de configuração que, no caso do Maven 2, é “4.0.0”.
<groupId>br.mec.siep</groupId> Informa ao Maven o grupo ao qual seu projeto pertence.
<artifactId>atualizador</artifactId> É o nome do seu projeto para o Maven.
<packaging>war</packaging> Define o tipo de artefato que este projeto deve gerar, no nosso caso, definimos o artefato como um “war”, mas poderia ser um “jar” ou qualquer outro tipo que o Maven venha a suportar.
<version>2.0.0</version> Indica a versão na qual o projeto se encontra. Por padrão, os desenvolvedores do Maven adotaram o versionamento das aplicações utilizando 3 números separados por “.” (pontos).
<name>Módulo Atualizador</name> É nome de exibição do projeto que será utilizado no momento da geração dos logs e na criação da documentação do projeto.
<dependency> É uma declaração de dependência do seu projeto, que será abordada mais a frente.
<scope>test</scope> É o escopo em que essa dependência deve ser utilizada pelo seu projeto.

Diretórios de um projeto Maven

Como já mencionamos, o Maven trabalha com uma estrutura padrão de diretórios, conforme o modelo abaixo:

Como pode-se perceber a estrutura de diretórios é bastante intuitiva. Vejamos:

  • src – é do diretório padrão de códigos fontes.
  • main – é o diretório principal do seu projeto.
  • java – é o diretório onde ficam os fontes java da sua aplicação.
  • resources – recursos como arquivos de configuração, imagens, etc.
  • Webapps – aplicação web java
  • site – tronco principal da documentação.
  • test – tronco de testes unitários e de integração.
  • java – é o diretório onde ficam os fontes de teste do Junit.
  • resources – recursos utilizados pelos testes da aplicação.
  • target – é o diretório criado automaticamente onde ficam os arquivos resultantes de qualquer tarefa executada durante o build do projeto.
  • Pom.xml – o arquivo de configuração do projeto Maven

Ao seguir a estrutura proposta, não é necessário indicar à ferramenta onde ficam os seus arquivos, pois ela sabe automaticamente onde procurar por eles. Um ponto importante desta estrutura é que ela separa os arquivos da aplicação dos arquivos dos testes da aplicação, assim, quando você gerar um “JAR” ou “WAR” do sistema, os seus testes não vão junto, porque não há necessidade de se empacotar testes unitários junto com o sistema.

Nas pastas “java” só deve-se colocar aquivos “.java” (arquivos de código fonte), pois qualquer outro tipo de arquivo será ignorado pelo Maven e seus plugins. Se houver a necessidade de adicionar arquivos de configuração no classpath da aplicação eles devem estar dento da pasta “resources”, pois é nela que o Maven procura por estes arquivos.

A pasta “webapp” só é necessária se o projeto em questão for de uma aplicação web.. A pasta “webapp” contém os arquivos comuns de uma aplicação web Java, como os JSPs, imagens, e as pastas “WEB-INF” e “META-INF”, como é definido na estrutura de diretórios das aplicações web em Java. Os arquivos de configuração da aplicação, como o “web.xml”, permanecem sendo colocados na pasta “webapp/WEB-INF“, e não em “resources”. Vale lembrar que só irão para as pastas “resources” os arquivos de configuração que precisam estar no classpath da aplicação.

A pasta “site” contém os arquivos de documentação que vão ser utilizados para gerar um “mini-site” do projeto, com informações extraídas dom POM e de outros plugins utilizados, como geradores de relatórios de análise de código.

Existe ainda a possibilidade de se alterar essa estrutura de diretórios para uma disposição de sua preferência, porém, seria necessário declarar no pom.xml quais diretórios são estes e para que devem ser utilizados. O Maven e vários plugins desenvolvidos para ele, no entanto, já vêm preparados para utilizar esses diretórios por padrão, logo, não é muito recomendado alterar esta estrutura.

Repositórios e Dependências

As dependências de um projeto para o Maven são os arquivos ou bibliotecas (arquivos “JAR”) que ele precisa em alguma das fases do seu ciclo de vida. Em nosso arquivo POM de exemplo, declaramos uma dependência no JAR do JUnit, para que pudéssemos utilizar as classes do JUnit no projeto. Todas as dependências necessárias para o projeto devem ser definidas no POM, para que o Maven possa utilizá-las nas fases do ciclo de vida do projeto que elas são necessárias.

Uma dependência é definida no nó <dependencies/> do POM. Cada nó deste tipo tem os seguintes nós componentes (existem outros além dos aqui definidos):

<groupId/> – O valor do “groupId” do POM da dependência

<artifactId/> – O valor do “artifactId” do POM da dependência

<version/> – O valor da “version” do POM da dependência

<scope/> – O escopo do ciclo de vida do projeto no qual esta dependência vai estar disponível

Os nós são todos auto-explicativos, ainda mais que já foram descritos no POM de exemplo. No entanto, há um que dizamos para explicar neste momento: o <scope/>. Ele define quando uma dependência está ou não disponível para o projeto. Este nó pode assumir os seguintes valores:

  • compile – A dependência fica disponível durante todas as fases do projeto, desde a compilação até a instalação do sistema. Deve ser utilizada para dependências que são chamadas diretamente pelo código. Este é o escopo padrão do Maven quando nenhum escopo é definido (o nó <scope/> em uma dependência é opcional).
  • provided – A dependência está disponível para compilação mas em tempo de execução ela deve ser disponibilizada pelo ambiente no qual a aplicação está executando. Um exemplo deste escopo é a API de Servlets, pois nós precisamos utilizar ela para compilar os nossos sistemas Java para a Web, mas não é necessário empacotar a aplicação com ela para rodar em um servidor web, o próprio servidor se encarrega de fornecer uma implementação.
  • runtime – É o contrário de provided, a dependência não está disponível em tempo de compilação, mas é enviada junto com o projeto em tempo de execução. Normalmente é utizado para bibliotecas que são carregadas dinamicamente (como drivers JDBC) e que não precisam estar disponíveis para que o sistema seja compilado.
  • test – A dependência só vai estar disponível para a execução dos testes do sistema e não vai ser enviada junto com a aplicação. Deve ser utilizada para bibliotecas que são utilizadas apenas para testar o sistema, como a biblioteca do JUnit no nosso exemplo, que só está disponível no escopo test.
  • system – Indica que a dependência não estará disponível no repositório do Maven e sua localização deve ser fornecida dentro do POM.

Definir um escopo errado tanto pode fazer com que o projeto contenha bibliotecas inúteis (como adicionar bibliotecas de teste ao ambiente de produção) como também podem fazer com que ele simplesmente não funcione (como deixar uma dependência que deveria ser “runtime” como “provided”).

Um repositório para o Maven é uma estrutura de diretórios e arquivos na qual ele armazena e busca por todas as dependências dos projetos que ele gerencia. Sempre que for declarada uma dependência em um projeto, o Maven sai em busca dessa dependência no seu repositório local (normalmente fica em sua pasta de usuário”/.m2/repository, no Windows XP seria algo como “C:\\Documents and Settings\seu_usuário\.m2\repository”), se ele não encontrar nada no repositório local, vai tentar buscar a dependência em um dos seus repositórios remotos (na internet) que vem configurados automaticamente na ferramenta (você também pode definir outros repositórios além dos padrão).

Um repositório segue uma estrutura simples de pastas baseadas nas identificações do próprio projeto, através das informações disponíveis nos nós <groupId/>, <artifactId/> e <version/>. O Maven define a estrutura de pastas da seguinte forma:

Para declarar esta dependência no nosso POM, ela seria definida da seguinte forma:

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate</artifactId>
  <version>3.1.3</version>
  <scope>test</scope>
  <type>jar</type>
</dependency>

A primeira parte da URL é o caminho para o repositório (que neste caso é o repositório remoto do Ibiblio, mas poderia ser o seu repositório local), a segunda parte é o valor do <groupId/> onde a cada “.” encontrado, uma nova pasta é criada (“org.hibernate” torna-se “/org/hibernate/”), a terceira parte é o valor do <artifactId/> (se houverem pontos aqui eles vão ser inseridos no nome, não são criadas novas pastas como no <groupId/>).

A última parte é o próprio arquivo em si, que também tem o seu nome gerado com base nas informações do POM. Na declaração da dependência do JUnit no nosso POM anterior, não havia a tag <type/>, porque a definição dela é opcional, quando você não a define, o Maven assume automaticamente que a dependência é um arquivo “.JAR”. O Maven também adiciona um “-“ (hífen) entre o <artifactId/> e a <version/> na hora de gerar o nome do arquivo.

Um ponto importante sobre dependências no Maven é que ele também gerencia as “dependências das dependências” do seu projeto. Por exemplo, Frameworks como o Hibernate utilizam várias outras bibliotecas e o Maven utiliza a própria descrição da dependência (o seu POM) para descobrir quais são as suas dependências e as traz junto para o projeto. sendo assim, não se precisa preocupar em saber todas as bibliotecas que precisam ser adicionadas ao classpath, pois isso é feito automaticamente pelo Maven.

Exemplo de utilização

Utilizando o Maven no DADT

Para migrarmos os projetos atualmente baseados no padrão do IDE Eclipse para o padrão do Maven, basicamente, é necessário distribuirmos o conteúdo dos projetos dentro de uma estrutura de diretórios, no padrão Maven, criada previamente. (Isso poderá ser feito de forma mais descomplicada utilizando o plugin do Maven para o Eclipse, conforme mosdrado na seção “Integrando o Maven 2 com o Eclipse”). Para exemplificarmos, tomaremos como exemplo uma aplicação WEB simples.

Um projeto Eclipse Web tem, essencialmente, duas pastas principais: WebContent e src. Sendo assim, o conteúdo de cada uma dela deve ser movido para, respectivamente, src/main/webapp e src/main/java da estrutura de diretórios criada.

Em seguida, devemos criar, na raiz do projeto maven, o pom.xml, arquivo de configuração do projeto. As bibliotecas, que normalmente estariam dentro de webapp/WEB-INF/lib, devem ser declaradas dentro da marcação <dependencies>. Caso isso não seja feito, provavelmente, iremos nos deparar com um erro de compilação (se necessário em tempo de compilação).

Porém, às vezes, o projeto depende de uma biblioteca ou framework que não está disponível em nenhum dos repositórios do Maven, seja pelo motivo de não ser open-source ou porque ninguém a colocou em nenhum repositório. Nesses casos, para adicionar uma biblioteca, temos que fazer com que ela esteja disponível no repositório local da máquina que está sendo utilizada. Para fazer isso, precisamos do “JAR” da biblioteca e de um POM com a declaração dessa biblioteca. Vejamos um exemplo com a biblioteca gráfica thinlet:

<?xml version="1.0" encoding="UTF-8"?>
<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.thinlet</groupId>
  <artifactId>thinlet</artifactId>
  <version>1.0.0</version>
</project>

Como podemos perceber, esse POM é mínimo, contando apenas com as informações obrigatórias do projeto. A partir desta definição, nós já sabemos que o caminho para a biblioteca no repositório deve ser: “caminho-para-o-repositório-Maven”/ com/thinlet /thinlet/1.0.0/thinlet-1.0.0.jar.

Então, nós só precisamos renomear o JAR do Thinlet para “thinlet-1.0.0.jar”, copiá-lo para a pasta “com/thinlet/thinlet/1.0.0/” e colocar, nesta mesma pasta, o POM descrito acima com o mesmo nome do arquivo JAR, mudando apenas a extensão para “.pom”, ele ficaria como “thinlet-1.0.0.pom”. O POM deve ter o mesmo nome do artefato porque é a partir do nome do artefato que o Maven sabe o nome do seu arquivo de configuração e baixa as suas dependências.

A maioria dos arquivos JAR que fazem parte do Java (como o JavaMail, o Activation, o Connector) não estão disponíveis nos repositórios do Maven, então, provavelmente, teremos que adicioná-los manualmente desta forma ao seu repositório local. Devemos prestar atenção aos erros indicados pelo Maven, quando ele indicar uma dependência que não pode ser encontrada, provavelmente é o caso de adição manual no seu repositório.

Para facilitar o desenvolvimento de forma descentralizada, seria ideal que tivéssemos um repositório do Maven mantido pela equipe de infraestrutura. O mesmo serviria tanto para os testes de integração contínua quanto para os desenvolvedores nos diversos núcleos da DADT. Sempre que houvesse a necessidade de uma nova biblioteca por parte de algum núcleo, seria solicitada a sua inclusão nesse repositório central.

Integrando o Maven 2 com o Eclipse

O Maven 2 tem plugins para integração com o Eclipse. Para sua instalação, antes, devemos ter o Maven 2 o Eclipse devidamente instalados.

Para instalar o plugin no Eclipse, siga os seguintes passos:

1. Selecione o menu “Help”

2. Selecione a opção “Software Updates”

3. Selecione a opção “Find and Install”

4. Na tela que aparece, escolha a opção “Search for New Features do Install” e clique no botão “Next”

5. Na tela que aperece, clique no botão “New Remote Site”, digite o nome “Maven 2 Plugin” no campo “Name” e a URL http://m2eclipse.codehaus.org/ no campo “URL”. Clique no botão “OK”.

6. Veja se o quadro ao lado do nome “Maven 2 Eclipse” na lista está marcado, se não estiver, marque-o.

7. Clique no botão “Finish”.

Deve aparecer uma tela pedindo confirmação sobre a instalação do plugin. Confirme a instalação e o Eclipse vai começar a baixar os arquivos necessários automaticamente. Quando ele terminar, vai pedir para reiniciar, deixe ele reiniciar e agora você já tem o plugin do Maven 2 instalado no seu Eclipse.

O plugin permite executar o Maven 2 de dentro do Eclipse e adiciona automaticamente qualquer dependência do POM no classpath do projeto do Eclipse. Para transformar um projeto comum em um projeto gerenciado pelo Maven, basta clicar com o botão direito do mouse na pasta do projeto, procurar a opção “Maven 2” e clicar na opção “Enable”. Se o projeto já tiver um “pom.xml” o Maven simplesmente usa este POM como configuração para o projeto, se ainda não existe um POM, ele vai mostrar um formulário para que você possa indicar as informações iniciais do projeto.

O plugin também permite que você adicione dependências sem ter que alterar diretamente o arquivo de configuração. Basta clicar com o botão direito do mouse na pasta do projeto, ir na opção “Maven” e selecionar a opção “Add Dependency”, um formulário onde você pode digitar o nome da dependência vai aparecer e você vai poder fazer uma busca por ela nos repositórios configurados no seu Maven. A parte de busca do plugin ainda tem alguns problemas, então mesmo que você não encontre a dependência, ela pode estar disponível no plugin, mas provavelmente não pode ser indexada por algum motivo, então em alguns momentos ainda pode ser necessário alterar diretamente o POM para adicionar uma dependência ao seu projeto.

Adicionar o plugin do Maven ao seu Eclipse vai facilitar ainda mais a gerência do seu classpath, pois não vai mais ser preciso ficar colocando todos os JAR que ele depende dentro do próprio projeto, pois o classpath vai ser gerenciado pelo Maven e a configuração do POM do projeto.

Referências

COSTA, Fabrício S. Criando um projeto Maven no Linux. Disponível em: http://fabriciojf.blogspot.com/2009/03/criando-um-projeto-maven-no-linux.html. Acesso em: 25/11/2009.

JUNIOR, Maurício Linhares de Aragão. An introduction to Maven 2. 24/01/2008. Disponível em: http://pbjug.org/jugs/documentos/maven_2. Acesso em: 28/12/2009.

PACHECO, Diego. Dez motivos para você usar Maven. 09/04/2009. Disponível em: http://imasters.uol.com.br/artigo/12336/java/dez_motivos_para_voce_usar_maven. Acesso em: 25/11/2009.

SANTOS, Felipe. Apache Maven – O canivete suíço. 05/10/2009. Disponível em: http://felipemsantos.wordpress.com/2009/10/05/apache-maven-o-canivete-suico. Acesso em: 28/12/2009.

  1. guarda moveis Apr 7th, 2012 @ 02:01 | #-49

    tudo indica que é um bom sistema

  2. moveis de escritorio Oct 2nd, 2012 @ 12:24 | #-48

    Suas informações agregaram muito sobre o tema. Valeu!

  3. anderson Oct 5th, 2012 @ 09:35 | #-47

    Disponha! Em breve, nas férias, irei atualizar todos os conteúdos do guia do desenvolvedor. Inclusive com novas técnicas e ferramentas.

  4. self storage May 3rd, 2013 @ 08:33 | #-46

    Procurava esse conteúdo á tempos na web, valeu.

  5. Ilton Barbosa Oct 10th, 2013 @ 10:05 | #-45

    Oi Anderson,
    Pode, por favor, me dá uma dica?
    Converti o meu projeto para Maven, só que ele continua buscando as bibliotecas na pasta LIB, pois, se eu apagar os arquivos desta pasta, o sistema não funciona.
    Como faço para ele não mais buscar os arquivos na pasta LIB?

  6. Ilton Barbosa Oct 10th, 2013 @ 10:08 | #-44

    Opa, esqueci de marcar a opção de me notificar por e-mail quando responder à minha pergunta.
    Pode, por favor me avisar?

  7. Mudanças Sep 24th, 2014 @ 22:10 | #-43

    Excelente posts Anderson! quero ficar atualizado dos próximos!
    abraços!

  8. Series Online Apr 10th, 2015 @ 13:31 | #-42

    Legal, gostei.

Submitting Comment, Give me a second...

Leave a comment

 

Allowed tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
Trackbacks & Pingbacks ( 0 )
  1. No trackbacks yet.