Capítulo 1

O medo de se adaptar

Ao desenvolver projetos é comum que precisemos nos adaptar a situações novas e, assim, modificar o sistema para melhorar as lógicas já existentes ou implementar uma funcionalidade nova.

Mas a própria palavra adaptação já nos dá um sentimento ruim sobre o que vai acontecer, pois muitas vezes a ligamos com "fazer gambiarras" em vez de pensar em ações limpas e evolutivas.

Outra palavra que causa desconforto é mudança. É corriqueiro pensarmos em mudança como perda, seja de trabalho, de privacidade, ou mesmo de alguns trechos de código que penamos para construir no passado e dos quais nos orgulhamos.

Contudo, mudanças e adaptações são necessárias e naturais durante a vida de qualquer projeto. Resistir a elas é fonte de diversos problemas que hoje vemos acontecendo em grande parte das empresas de desenvolvimento de software, como funcionalidades com falhas, adiamento de atualizações e criação de novas lógicas ao invés de alterar as já existentes.

1.1 Caindo de paraquedas em um projeto

Quando entramos em um projeto, é comum que tenhamos medo de mexer em alguma coisa e quebrar dezenas de outras. Mas por que temos esse medo de quebrar código já existente? Porque, dependendo da mudança que efetuamos no código, fica bem difícil voltar ao estado anterior.

Não é de hoje que esse problema existe, por isso, já há diversas formas de contorná-lo. Por exemplo:

O problema com essas abordagens é que elas são todas muito manuais, além do que na segunda abordagem ainda corremos o risco de alguém sem querer tirar o comentário do código e termos comportamentos inesperados. Código comentado é um exemplo do que chamamos de "Code Smells" ou, na tradução mais frequente, "Maus cheiros de código". Os Code Smells são sintomas de más práticas e devem ser tratados assim que possível.

Bibliografia sobre Code Smells

Se você gostaria de estudar mais sobre os chamados Code Smells, há três livros bastante conhecidos onde há explicações ou catálogos sobre tais sintomas. São eles:

Todas essas soluções são para resolver o mesmo problema: versionar um arquivo. Pensando nisso, foram criadas ferramentas para controle de versões. Dentre elas, algumas ganharam bastante destaque, como, por exemplo:

Todas as ferramentas citadas acima estão na categoria de controle de versão centralizado, ou seja, é necessário um lugar único para o servidor que irá controlar as versões e cada cliente terá que se conectar a esse servidor.

Há também ferramentas de controle de versão distribuído, em que cada cliente tem seu próprio repositório. Abaixo estão algumas que se destacaram bastante, todas criadas em 2005:

Já conhece os cursos online Alura?

A Alura oferece centenas de cursos online em sua plataforma exclusiva de ensino que favorece o aprendizado com a qualidade reconhecida da Caelum. Você pode escolher um curso nas áreas de Programação, Front-end, Mobile, Design & UX, Infra e Business, com um plano que dá acesso a todos os cursos. Ex aluno da Caelum tem 15% de desconto neste link!

Conheça os cursos online Alura.

1.2 Controle de versão com Git

O Git é um sistema de controle de versão com diversas características que o tornam interessante para o trabalho no mercado atual. Veremos elas durante esse curso.

Uma das características importantes é a de poder comitar nossas alterações na máquina local, mesmo que estejamos sem conexão com a internet ou com a rede interna onde está o repositório Git. Podemos só sincronizar com o repositório central no momento que considerarmos adequado.

Há duas formas para começarmos a trabalhar com o Git: fazer uma cópia de um repositório já existente na nossa máquina, processo conhecido por clone,

    $ git clone git://url.do.repositorio

ou criar um repositório local.

    $ git init

Agora podemos alterar ou adicionar novos arquivos ao repositório.

Após fazer isso, podemos usar o comando git status para ver quais arquivos foram modificados:

    $ git status
      # On branch master
      # Changes to be committed:
      #   (use "git reset HEAD <file>..." to unstage)
      #
      #    modified:   arquivo.que.sera.comitado
      #
      # Changes not staged for commit:
      #   (use "git add <file>..." to update what will be committed)
      #   (use "git checkout -- <file>..." to discard changes in working directory)
      #
      #    modified:   arquivo.modificado.mas.que.nao.sera.comitado
      #
      # Untracked files:
      #   (use "git add <file>..." to include in what will be committed)
      #
      #    arquivo.que.o.git.nao.esta.gerenciando.ainda

Essa resposta diz qual é o status do seu repositório local e o que você pode fazer com as alterações. Os arquivos novos, que ainda não existem no repositório, aparecem na seção Untracked files e os já existentes, mas com alteração, aparecem em Changes not staged for commit. O processo de enviar mudanças ou criações de arquivos ao repositório é conhecido por commit, mas por padrão o Git só comitará os arquivos que estiverem na seção Changes to be commited. Devemos então usar o comando git add passando o caminho de todos os arquivos que queremos adicionar ao próximo commit, tanto os já existentes quanto os novos, como o Git está sugerindo:

    $ git add arquivo.que.o.git.nao.esta.gerenciando.ainda arquivo.modificado.mas.que.nao.sera.comitado

Podemos rodar o git status novamente e verificaremos que todos os arquivos estarão na seção Changes to be commited. Podemos então efetuar o commit já informando uma mensagem que descreva o que foi feito.

    $ git commit -m "Incluindo testes novos para o sistema de pagamento via cartão."

Quando a intenção for a de adicionar todos os arquivos que estão em Changes not staged for commit, existe um atalho:

    $ git commit -a -m "Efetuando um commit local com todos os arquivos de uma única vez."

Ao executar o git status novamente, o resultado é que não existe mais nenhuma pendência:

    $ git status
      # On branch master
      nothing to commit (working directory clean)

A partir desse instante, podemos voltar para qualquer versão comitada anteriormente. Fazemos isso usando o comando git reset --hard e passando um identificador de versão.

    $ git reset --hard identificadorDeVersao

Para obter um histórico dos commits do seu repositório e descobrir o identificador da versão desejada, podemos usar o comando:

git log

Será produzida uma saída como essa:

    commit 1c57c4f27f3f18d46093f5fbc5cf2a8b330f13d6
    Author: Josenildo <jose@nildo.com.br>
    Date:   Wed Nov 24 15:00:24 2010 -0200

        Otimizando a hidrodinâmica

    commit 6abf51de170ae09e20aede3b0a01f5aa27f39299
    Author: Marivalda <marivalda@zip.com.br>
    Date:   Wed Nov 24 14:41:59 2010 -0200

        Corrigindo avarias na asa

    commit b28152b62c1d2fca891784423773c0abef0b03c2
    Merge: cdbbcc9 fbbe794
    Author: Claudineide <clau@clau.com>
    Date:   Wed Nov 24 13:51:32 2010 -0200

        Adicionando outro tipo de combustível

É possível mostrar um resumo, em apenas uma linha, do histórico de commits de um repositório utilizando a opção --oneline:

git log --oneline

A resposta será algo como:

1c57c4f Otimizando a hidrodinâmica
6abf51d Corrigindo avarias na asa
b28152b Adicionando outro tipo de combustível

Para limitar o número de commits, há a opção -n:

git log --oneline -n 2

Teremos:

1c57c4f Otimizando a hidrodinâmica
6abf51d Corrigindo avarias na asa

Às vezes percebemos que escrevemos código errado antes mesmo de comitar um arquivo e desejamos reverter esse arquivo para o estado anterior. Com o Git, basta usar o comando:

    git checkout arquivo.errado

Para que o git consiga fazer o commit no nosso repositório, temos que informar para ele qual a conta que será usada para enviar as alterações e qual o nome que deve ser utilizado nas mensagens de commit. Para isso, vamos executar os comandos:

$ git config --global user.name "<Digite seu nome aqui>"

$ git config --global user.email "<Digite o mesmo e-mail da sua conta>"

O comando git config é utilizado para adicionar/substituir alguma configuração. A opção --global indica que essa configuração é global para o usuário logado atualmente no computador, ou seja, o git utilizará as mesmas configurações para a conta logada atualmente na máquina.

Mais sobre Git

Com o Git é possível fazer muito mais coisas do que vamos falar no curso. É possível fazer commits parciais, voltar para versões antigas, criar branches, etc Além disso existem interfaces gráficas que ajudam a fazer algumas das operações mais comuns, como o gitk, gitg e gitx.

Aprenda mais sobre o Git em: http://help.github.com/

1.3 Exercício - Iniciando com Git

  1. Através do terminal, crie um novo diretório com o nome perfil e inicie um repositório em branco dentro dele:

    $ mkdir perfil
    $ cd perfil
    $ git init
    
  2. No diretório perfil, crie um arquivo de texto com o nome bio.txt, altere o conteúdo dele inserindo seu nome e verifique o estado do repositório:

    $ touch bio.txt
    $ echo "Seu nome e sobrenome" >> bio.txt
    $ git status
    

    Como você pode observar, o arquivo ainda não está sendo rastreado pelo git, isso é, está como untracked.

  3. Faça com que o arquivo seja rastreado (tracked) pelo git para podermos enviá-lo ao repositório. Em seguida, verifique novamente o estado do repositório:

    $ git add bio.txt
    $ git status
    
  4. Antes de efetuar qualquer commit, é necessário configurar o nome e o email do seu usuário no Git. Digite:

    $ git config --global user.name "<Digite seu nome aqui>"
    $ git config --global user.email "<Digite seu e-mail aqui>"
    
  5. Envie o arquivo ao repositório e depois confira o estado do repositório:

     $ git commit -m "Adicionando arquivo bio"
     $ git status
    
  6. Verifique qual o identificador, hash, do commit que você acabou de fazer:

    $ git log
    

    Caso o histórico dos commits ocupe a tela inteira do terminal, aperte a tecla q para voltar à linha de comando.

  7. Inclua novas linhas no arquivo com algumas informações sobre o que você gosta de fazer e verifique novamente o estado do seu repositório:

    $ echo "Gosto de programar, tocar violão e praticar esportes!" >> bio.txt
    $ git status
    

    Perceba que o arquivo está em um estado diferente. Antes de fazer o primeiro commit, o arquivo estava untracked, mas, como o git já está rastreando esse arquivo, ele está no estado not staged.

  8. Para enviar as mudanças ao repositório, precisamos primeiro passar o arquivo alterado para staged e então efetuar o commit do mesmo. Faremos esses dois passos de uma vez:

     $ git commit -am "Adicionando atividades preferidas."
    

1.4 Serviços de repositório de código

Seja qual for a opção por sistema de controle de versões, há diversos serviços que disponibilizam espaço gratuito para os repositórios dos projetos. Em alguns, a condição para a gratuidade do serviço é que o código fique aberto, em outros é possível ter repositórios fechados, mas com algumas restrições.

Para casos onde os clientes possuem um acordo de que o código não pode ficar retido em ambientes de terceiros, tais serviços não são suficientes. Nesse caso, pode ser instalada em uma máquina da empresa alguma ferramenta que gerencie o git no servidor como o Bonobo (https://bonobogitserver.com/), se o sistema for Windows, ou seguir o tutorial (https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols), se for Linux.

Contudo, com a ênfase recente em elasticidade e contratação de software como serviço, a importância de terceirizar essa infraestrutura tem crescido dentro das empresas. Dos serviços online, destacamos alguns deles:

Durante o curso, utilizaremos o GitHub como repositório de código remoto. Ao acessar https://github.com, veremos a seguinte página:

Homepage Github

Figura 1.1: Homepage Github

No caso de ainda não termos uma conta, podemos criá-la preenchendo os campos: Pick a username, Your email address e Create a password.

Após preencher esses campos, vamos clicar no botão Sign up for Github. Assim, acabamos de fazer a primeira das 3 etapas do processo de criação de conta.

A segunda etapa é selecionar o tipo de conta que queremos usar. O GitHub tem uma modalidade gratuita e uma paga. Na modalidade gratuita, podemos criar repositórios públicos ilimitados. Já na modalidade paga, você tem a possibilidade de criar repositórios públicos e privados com um custo mensal ou anual.

Welcome page step 2

Figura 1.2: Welcome page step 2

Na terceira etapa, podemos selecionar um nível de experiência, o(s) uso(s) que pretendemos dar à nossa conta do GitHub e o que melhor nos descreve.

Welcome page step 3

Figura 1.3: Welcome page step 3

Após preenchermos tudo, será enviado um e-mail de confirmação e será exibida uma tela onde poderemos escolher entre ler um guia e iniciar um projeto.

Dashboard

Figura 1.4: Dashboard

Quando clicarmos em Start a Project, será exibida uma tela informando que precisamos confirmar a criação da nossa conta através do nosso e-mail:

Verificação do e-mail

Figura 1.5: Verificação do e-mail

Ao analisarmos o e-mail recebido, vemos o link para a verificação Verify email address :

Email de verificação

Figura 1.6: Email de verificação

Ao clicarmos nesse link, seremos redirecionados para a tela de configuração da nossa conta:

Verificado

Figura 1.7: Verificado

Com isso, nossa conta será criada e estará pronta para ser usada.

Saber inglês é muito importante em TI

Na Alura Língua você reforça e aprimora seu inglês! Com Spaced Repetitions a metodologia se adapta ao seu conhecimento. Com FlashCards, os exercícios são objetivos e focados em uma habilidade específica, para praticar tudo que aprendeu em cada lição. Diversas estatísticas indicarão como prosseguir, analizando quais são seus pontos fortes e fracos, frases e estruturas já conhecidas.

Pratique seu inglês na Alura Língua.

1.5 Exercício Opcional - Criando uma conta no Github

(pule este exercício caso já tenha uma conta)

  1. Acesse https://github.com .
  2. Preencha os campos:

    • Pick a username
    • Your email address
    • Create a password
    • Clique em Sign up for Github
    • Homepage Github

      Figura 1.8: Homepage Github

  3. Selecione o tipo de conta que você quer usar:

    • Gratuita: repositórios públicos ilimitados
    • Paga: repositórios privados e públicos ilimitados
    • Welcome page step 2

      Figura 1.9: Welcome page step 2

  4. Selecione:

    • O seu nível de experiência com programação,
    • Para que você planeja usar o Github,
    • A opção que lhe descreve melhor.

      Por fim, descreva seus interesses:

      Welcome page step 3

      Figura 1.10: Welcome page step 3

  5. Após clicar em Submit, será exibido uma tela de dashboard:

    Dashboard

    Figura 1.11: Dashboard

  6. Se clicarmos em Start a project, será avisado que precisamos verificar nosso e-mail para ativar nossa conta:

    Verificação do e-mail

    Figura 1.12: Verificação do e-mail

  7. No e-mail que foi enviado pelo GitHub, vamos clicar no link Verify email address:

    Email de verificação

    Figura 1.13: Email de verificação

  8. Feito isso, seremos redirecionados para a tela de configurações da nossa conta indicando que nossa conta foi ativada:

    Verificado

    Figura 1.14: Verificado

1.6 Utilizando GitHub

Como mencionado anteriormente, utilizaremos o GitHub como nosso repositório remoto de código.

Inclusive, o projeto base para o curso encontra-se em https://github.com/caelum/fj22-ingressos.git:

Projeto Base

Figura 1.15: Projeto Base

O objetivo desse projeto é simular a venda de ingressos em um cinema e decidiram utilizar Spring MVC e Hibernate na aplicação. O código já está iniciado e já possui algumas funcionalidades, como adicionar salas e filmes, mas ainda não está finalizado. Nós vamos continuar esse projeto para permitir a compra de ingressos.

Porém, ele está na conta da caelum e, a menos que algum administrador nos libere o acesso a esse repositório, não será possível enviar nosso código local diretamente para esse projeto (push).

Felizmente, como esse repositório está público, podemos fazer uma cópia do mesmo para nossa conta. Esse processo de copiarmos um repositório de outra conta para a nossa é chamado de Fork.

Se reparamos bem, na página há um botão chamado Fork:

Botão Fork

Figura 1.16: Botão Fork

Ao clicarmos nesse botão, será exibido uma animação indicando que o repositório está sendo copiado para nossa conta.

Fork em andamento

Figura 1.17: Fork em andamento

Ao término será exibido o mesmo repositório, só que em nossa conta:

Fork encerrado

Figura 1.18: Fork encerrado

Agora sim podemos fazer um git clone do repositório em nossa conta e começar a desenvolver.

README.md

É muito comum ter em repositórios um texto contendo a finalidade do projeto, informações sobre os desenvolvedores ou sobre a utilização do projeto em si. Para exibir essas informações, podemos criar um arquivo na raiz do repositório chamado README.md. Nesse arquivo, podemos escrever utilizando a linguagem de marcação Markdown, que tem uma syntax simples para formatar o texto. Para saber mais sobre markdown, consulte: https://daringfireball.net/projects/markdown/syntax

README

Figura 1.19: README

1.7 Exercício - Fork e Clone do projeto

  1. Para poder enviar commits no projeto fj22-ingressos, faça um fork do repositório
    fj22-ingressos da conta da Caelum para a sua conta:

  2. Fora do repositório anterior, perfil, clone o seu projeto, que está em
    https://github.com/<Seu usuario aqui>/fj22-ingressos.git:

     $ git clone https://github.com/<Seu usuario aqui>/fj22-ingressos.git
     $ cd fj22-ingressos
    
  3. Crie um arquivo chamado README.md na pasta fj22-ingressos com um conteúdo de descrição sobre você. Depois, verifique qual o status de seu repositório:

    $ touch README.md
    $ echo "Descrição sobre você" >> README.md
    $ git status
    
  4. Adicione o arquivo para ser rastreado pelo git:

    $ git add README.md
    
  5. Execute um commit com uma mensagem de descrição condizente, por exemplo:

    $ git commit -m "adicionando descrição sobre um contribuinte novo ao projeto"
    
  6. Por fim, envie as alterações comitadas para o repositório remoto:

     $ git push
    

Aprenda se divertindo na Alura Start!

Na Alura Start você vai criar games, apps, sites e muito mais! É hora de transformar suas ideias em programas de verdade! Suas animações e programas também te ajudam a conhecer mais de biologia, matemática e como as coisas funcionam. Estude no seu ritmo e com a melhor didática. A qualidade da conceituada Alura, agora para Starters.

Conheça os cursos online da Alura Start!

1.8 Lidando com build e dependências

Hoje em dia é muito fácil fazer o build de um projeto Java devido às facilidades que nossos IDEs nos proporcionam.

O IDE se encarrega de colocar nossas dependências no classpath, bastando apenas dizer quais são as dependências, se encarrega também de criar o diretório em que ficarão nossas classes já compiladas, de compilar o projeto, de empacotar a aplicação entre outras funções. Podemos até interferir nesse processo adicionando plugins para coletar métricas, extrair relatórios, fazer o deploy, entre outras coisas.

Porém, em alguns desses processos que nosso IDE facilita, ainda há muita intervenção manual. Por exemplo: imagine que no nosso projeto precisamos usar o Hibernate. Para colocar a dependência do Hibernate no classpath, precisamos baixar o .jar do Hibernate e todos os arquivos .jar que o Hibernate precisa para funcionar. Imagine agora que, nesse mesmo projeto, também vamos usar Spring. Precisamos então baixar o .jar do Spring e todos os .jar de que o Spring depende.

Até agora nenhum problema, exceto o fato de termos que ficar baixando um monte de arquivos .jar. Mas e se o Spring e o Hibernate dependerem do mesmo arquivo .jar? Em casos como esse, para não ter nenhuma duplicidade, ou pior, ter a mesma dependência em versões diferentes teremos que lidar com o conflito de dependências manualmente, sempre olhando se a dependência em questão já está no nosso projeto antes de baixar.

Esse problema é tão comum que foram criadas várias ferramentas para automatizar processos como o de build e o de gerenciamento de dependências.

Em Java, temos uma ferramenta bem popular para automação do build chamada Ant. Com ela, escrevemos em um arquivo xml nosso script de build, declarando os passos necessários para construir o projeto, como criar o diretório de output, compilar nossas classes, compilar nossos testes, rodar nossos testes, empacotar a aplicação, etc.

Porém, apenas com ela, ainda ficávamos sem a gestão das nossas dependências e, por isso, usávamos outra ferramenta, chamada Ivy.

Para usar o Ivy, também usamos um arquivo xml onde declaramos nossas dependências. Ele então consegue baixá-las através de um repositório central.

Usando a soma do Ant e do Ivy, conseguíamos uma forma versátil e automatizada para nosso processo de build completo.

Posteriormente, uniram o que tem de melhor no Ant e no Ivy e criaram uma ferramenta híbrida chamada Maven.

Com o Maven, temos um único arquivo xml chamado pom.xml e, nesse arquivo, declaramos todas as dependências e plugins necessários para nosso processo de build, run ou deploy.

O arquivo pom.xml tem a seguinte estrutura básica:


<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">


  <!--Informações básicas do seu projeto-->
  <groupId>br.com.caleum</groupId>
  <artifactId>fj22-ingresso</artifactId>
  <version>1.0</version>

  <!--Configurações do build * Opcional-->
  <build>
      ...
  </build>

  <!--Declaração de dependências * Opcional-->
  <dependencies>

          <!--Declarando a dependência do hibernate-core na versão 5.2.6.Final -->
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>5.2.6.Final</version>
        </dependency>

  </dependencies>


</project>

Além disso, o Maven tem uma estrutura padrão de pastas que deve ser seguida, como visto a seguir:

+-src/
    |
    +- main/
    |    |
    |    +- java/
    |    +- resources/
    |    +- webapp/ (em caso de projetos web com empacotamento _.war_)
    |
    +- test/
        |
        +- java/
        +- resources/

O Maven também tem um ciclo de build bem definido que conta com as seguintes fases:

Ao instalar o Maven, é disponibilizado um utilitário em linha de comando chamado mvn.

A sintaxe desse utilitário é mvn seguido do goal(ação) que queremos executar. Os goals padrões são exatamente as fases do ciclo de build:

$ mvn validate
$ mvn compile
$ mvn test
$ mvn package
$ mvn verify
$ mvn deploy

Além desses, há muitos outros goals, como, por exemplo, o clean, que apaga o diretório de output gerado no processo de compilação.

Como o Maven tem um ciclo de build bem definido e cada fase depende das anteriores, ele sempre irá garantir que todas as fases antes do goal escolhido sejam executadas. Por exemplo, ao usar o goal test, o Maven irá executar as fases validate, compile e só depois a test, nessa ordem.

Podemos inclusive combinar goals. Por exemplo, se executarmos mvn clean package, o Maven chamará o goal clean, que faz a limpeza dos outputs, e o goal package, que compilará nosso projeto, rodará os testes e empacotará nossa aplicação.

Além dos goals padrões do Maven, podemos utilizar outros goals através de plugins.

A sintaxe de utilização de um plugin é mvn plugin:goal.

Ex.:

$ mvn dependency:tree

O plugin dependency seguido do goal tree, lista a árvore das dependências já baixadas na nossa aplicação.

Também existe um plugin do Maven para o Jetty. Para rodar o servidor, basta utilizar o comando mvn jetty:run.

Instalando o Maven em Casa

Para utilizar o Maven em casa, é necessário baixar os binários no site https://maven.apache.org/download.cgi e instalar seguindo os passos referentes ao seu sistema operacional que estão em https://maven.apache.org/install.html.

1.9 Exercício - Usando gerenciador de dependência e build

  1. Acesse o diretório do projeto, baixe as dependências e depois liste-as:

    $ cd fj22-ingressos
    
    $ mvn dependency:resolve
    
    $ mvn dependency:tree
    
  2. Empacote a aplicação e rode o jetty:

    $ mvn package
    
    $ mvn jetty:run
    

    Alternativamente, você pode rodar os dois comandos de uma só vez:

    $ mvn package jetty:run
    
  3. No navegador, acesse http://localhost:8080 e navegue pelo sistema.

  4. Pare o jetty e limpe o diretório target do seu projeto:

    • No terminal, pressione CTRL+C para interromper a execução do jetty.

    • Em seguida, execute:

        $ mvn clean
      

1.10 Exercício - Rodando projeto no Eclipse com maven

  1. Vamos importar o projeto no eclipse:

    • File >> import

    • Selecione Existing maven project

    • Escolha a pasta do projeto fj22-ingressos

    • Selecione o arquivo pom.xml que apareceu.

  2. Vamos configurar a execução através do Maven no eclipse:

    • Clique com o botão direito sobre o projeto e selecione: Run As >> Run configurations...
    • Clique com o botão direito sobre Maven Build >> New
    • Se o campo Base Diretory estiver vazio, clique em Workspace e selecione o projeto
    • No campo Name preencha com "Rodar com maven"
    • No campo Goals preencha com clean package jetty:run
    • Clique no botão Apply e depois em Run

  3. No navegador, acesse http://localhost:8080 e navegue pelo sistema.

Seus livros de tecnologia parecem do século passado?

Conheça a Casa do Código, uma nova editora, com autores de destaque no mercado, foco em ebooks (PDF, epub, mobi), preços imbatíveis e assuntos atuais.
Com a curadoria da Caelum e excelentes autores, é uma abordagem diferente para livros de tecnologia no Brasil.

Casa do Código, Livros de Tecnologia.