Utilizando Maven Nexus e Subversion 1

5/11/2018 Utilizando Maven Nexus e Subversion 1 - slidepdf.com

http://slidepdf.com/reader/full/utilizando-maven-nexus-e-subversion-1-55a0d04dec453

Tutorial: Utilizando Maven, Nexus ESubversion Em Projetos Java (Parte I)

Autor: Paulo Jerônimo

Última atualização: 07/07/2010 às 08:10 - Comentários: http://j.mp/mvnnexus-1

y Introdução

y Pré-requisitos

y Motivando o uso do Maven

y Uma introdução ao Maven o Criando os usuários que irão trabalhar com o Maven o Instalando o Maven o Gerando um projeto de negócios o Compilando, testando, instalando e implantando artefatos o Gerando um projeto Web que utiliza o framework Wicket o Compreendendo alguns detalhes no pom.xml do projeto Web o Executando a aplicação Web

o Vendo a árvore de dependências da aplicação Web y Uma introdução ao Nexus

o Motivando o uso do Nexus o Instalando o Nexus o Alterando as configurações do Maven para que ele use o Nexus

y Alterando o projeto web gerado inicialmente

y Alterando o projeto negócios gerado inicialmente

y Efetuando o deploy do projeto de negócios

y Finalizando a construção do projeto Web

y Extras

Introdução

No momento da escrita deste tutorial, o Lado Servidor esteve responsável por refazer a arquitetura de umaaplicação em um de seus clientes. Tal aplicação é composta por módulos de negócio empacotados em JARs epor uma camada de apresentação Web. A camada Web é produzida por uma equipe, que chamararemos deequipe web, e consome serviços implementados na camada de negócio por outro time, que compõe uma equipede negócios.

O trabalho de alteração da arquitetura deveria ser simples e rápido. Contudo, alguns problemas recorrentes(vivenciados pelo Lado Servidor em outros clientes) apareceram:

y Inexistência de scripts automatizados para a construção (build ) de aplicações, sem a dependência deum IDE;

y Dependências de módulos da aplicação (JARs) armazenadas junto com o código fonte em um SourceC ont r ol Management ( S CM);

y Dependências guardadas sem informações relativas a suas versões;

y Dependências e ordem de compilação entre os módulos de negócio visíveis somente aos arquivos de

configuração de um IDE;y Inexistência de procedimentos efetivos para:

o Controle de tags e branches do códigos fonte;o Versionamento, publicação e controle de artefatos binários e de suas dependências;

A ocorrência dos problemas acima motivou o Lado Servidor a escrever este tutorial e apresentar o Maven eo Nexus como solução para vários deles. E, atuando em parceria com umS CM , como o Subversion por exemplo, todos podem ser resolvidos.

O propósito deste tutorial é o de introduzir como estas ferramentas podem trabalhar em conjunto parasolucionar os problemas apresentados. Nele é abordado a instalação do Maven, do Nexus e do Subversion, e asimulação do trabalho de desenvolvedores das equipes (web e negócios) para gerar e publicar snapshots e



releases (conceitos que serão explicados aqui). Sua estrutura foi organizada para que as tarefas possam ser realizadas (passo a passo) apenas copiando e colando os comandos apresentados nas caixas que apresentamcomo executá-los.

Para fins didáticos, este tutorial também foi dividido em três partes:

y Esta primeira parte apresenta uma introdução as f erramentas Maven e Nexus;

y

A segunda parte apresenta como utilizar Maven, Nexus e Subversion na geração de releases;y A terceira e última parte, mais voltada a atividades de uma equipe de suporte, aprimora alguns

aspectos da infraestrutura;

Pré-Requisitos

Neste tutorial não é esperado conhecimento anterior no uso das ferramentas que serão apresentadas.Entretanto, ele foi concebido e testado num ambiente Linux Ubuntu 10.04, na plataforma x86-32. Sendo ass im,é necessário algum conhecimento básico de Linux para tarefas relativas a instalação/configuração.

Pelo fato dos comandos executados no Maven serem multi-plataforma, as tarefas relativas ao uso destasferramentas poderão ser executadas por quaisquer usuários que não tenham experiência anterior em Linux. Atémesmo pelo uso de outro sistema operacional como o Windows ou o MAC OS. Caso seja utilizando o Windows,recomendamos fortemente o uso doCygwin para a execução das tarefas deste tutorial.

Motivando O Uso Do Maven

O Maven é uma ferramenta que, no contexto dos problemas apresentados na introdução deste tutorial, trabalhacom as seguintes questões:

y Provê um mecanismo padronizado, e amplamente utilizado por desenvolvedores Java, na construçãode aplicações, de forma indenpendente de IDEs (mas integrável a eles);

y Realiza o controle de dependências dos artefatos, gerenciando inclusive, o controle das dependênciasdas dependências;

y Elimina a necessidade do armazenamento de artefatos binários noS CM pois pode trabalhar emconjunto com gerenciadores de repositórios oferecendo procedimentos efetivos para o versionamentodestes artefatos;

y Introduz um controle de releases adequado e integrado a ferramentas de S CM ;

Uma Introdução Ao Maven

Criando Os Usuários Que Irão Trabalhar Com O Maven

Vamos iniciar o tutorial criando dois usuários que representarão um membro da equipe de negócios e outro daequipe web. A execução do comando a seguir criará as contas necessárias:

C opie d o i ní ci o da palavra sudo até o a póst r ofo (') da úl t ima li nha. A seguir, c ole em seu shell:

$ sudo bash -c 'useradd -m -s /bin/bash web

useradd -m -s /bin/bash negocios'

Instalando O Maven

Agora vamos baixar e instalar o Maven 3.0. Ele será instalado no diretório /opt pois será compartilhado pelosusuarios negocios e web:

$ sudo bash -c 'cd /opt



wget -c http://mirror.pop-sc.rnp.br/apache/maven/binaries/apache-maven-3.0-beta-1-bin.tar.gztar xvfz apache-maven-3.0-beta-1-bin.tar.gzln -s apache-maven-3.0-beta-1 maven'

Para que o Maven possa funcionar na conta dos usuários criados, o arquivo ~/.bashrc de cada um delesprecisará indicar a localização de

$JAVA_HOME. Também precisaremos colocar seus binários no PATH do

usuário. A execução em sequência dos dois comandos a seguir configura o arquivo ~/.bashrc, para cada umdestes usuários:

$ cat > /tmp/bashrc <<'EOF'export JAVA_HOME=/usr/lib/jvm/java-6-openjdkexport M2_HOME=/opt/mavenexport PATH=$M2_HOME/bin:$PATHEOF$ for user in negocios web; do sudo su -c 'cat /tmp/bashrc >> ~/.bashrc'$user; done

Um detalhe que talvez chame a atenção: no Ubuntu (10.04), o JDK que está sendoutilizado por padrão é o OpenJDK (o pacote padrão anteriormente era o sun-java6-jdk). Sedesejarmos executar o JDK com este último pacote, os procedimentos são apontados por este link.

Agora, podemos testar a execução do Maven fazendo o login com a conta de qualquer um destes usuários. Oscomandos a seguir solicitam o login como o usuário web e, em seguida, a impressão da versão do Maven. Oexit (terceiro comando) solicita o logout do usuário:

$ sudo su - web$ mvn -v$ exit

Gerando Um Projeto De Negócios

Iniciaremos um novo projeto no Maven através do uso do plugin archetype. Arc hetypes são esqueletos geradospelo Maven para a codificação de novos projetos.

O projeto conterá métodos de negócios utilizados por uma aplicação W eb. Logo, vamos nos logar como ousuário negocios que será responsável pela codificação deste projeto. Os comandos a seguir, efetuam ologon deste usuário e solicitam a criação do projeto:

$ sudo su - negocios$ mvn archetype:generate -DarchetypeArtifactId=maven-archetype-quickstart

Observe atentamente (pela saída do comando) que o Maven realiza o download de vários JARs para realizar esta tarefa. Os arquivos baixados são instalados num repositório local (~/.m2/repository) e o motivo parao download de tantos arquivos é explicado um pouco mais a frente. Se outro desenvolvedor da corporaçãotambém precisar utilizar o Maven, o mesmo processo será repetido.

Se por acaso você estiver executando este tutorial numa rede em que é necessária a

configuração de um proxy para o acesso a Internet, antes de executar o comando acimaserá necessário configurar o Maven. Para fazer isto, configure oarquivo settings.xml conforme descrito no artigo "Configuring a proxy".

Após alguns downloads, o plugin de arc hetype, irá solicitar a resposta para algumas perguntas. Responda-asconforme apresentado na tela a seguir:

[INFO] Generating project in Interactive modeDefine value for property 'groupId': : ladoservidorDefine value for property 'artifactId': : testeDefine value for property 'version': 1.0-SNAPSHOT: :



Define value for property 'package': ladoservidor: : com.ladoservidorConfirm properties configuration:groupId: ladoservidorartifactId: testeversion: 1.0-SNAPSHOTpackage: com.ladoservidorY: :

Veja a estrutura do projeto que foi criado:

$ tree -a testeteste pom.xml src

main java com ladoservidor App.java test

java com

ladoservidor

AppTest.java

9 directories, 3 files

Compilando, Testando, Instalando E Implantando Artefatos

O esqueleto gerado pelo Maven contém o arquivo pom.xml. Ele é o principal arquivo utilizado pelo Maven. Onome do arquivo leva as iniciais de "Project Object Model" e o seu conteúdo pode ser visualizado com ocomando abaixo. Nele são definidas todas as questões principais acerca do projeto. Especificamente nestecaso, o tipo de pacote que será gerado no processo de contrução pelo Maven será um JAR (definido peloelemento packaging). Para que este JAR possa ser gerado, o maven executa fases no processo de contruçãoe, uma delas, é a fase de testes. Quando estiver nesta fase (que obviamente ocorre após a compilação) oMaven precisará baixar uma dependência, que é o JUnit. Então, ele fará o download do JUnit, na versão 3.8.1,buscando o JAR a partir de um dos seus repositórios públicos já pré-configurados. Em seguida, o arquivo

baixado será instalado no repositório local do usuário e, desta forma, ele poderá então utilizar esta dependênciana execução do TestCase codificado em com.ladoservidor.AppTest.

Mudando para o diretório do projeto e listando o conteúdo do arquivo pom.xml:

$ cd teste; cat 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/maven-v4_0_0.xsd"><modelVersion>4.0.0</modelVersion><groupId>ladoservidor</groupId><artifactId>teste</artifactId><packaging>jar</packaging><version>1.0-SNAPSHOT</version>

<name>teste</name><url>http://maven.apache.org</url><dependencies><dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>3.8.1</version><scope>test</scope>

</dependency></dependencies>

</project>



Se desejarmos apenas compilar os fontes da aplicação, sem testá-la, o comando a seguir serve a estepropósito. (N ot e que novament e uma série de arquiv os serão baixad os e i nst alad os no re posi tóri o l ocal):

$ mvn compile

Para executar os TestCases da aplicação gerada (classes que por convenção estão no diretóriosrc/test)executamos o comando abaixo. (Mai s uma vez, oc orre uma série de d ownl oad s... ):

$ mvn test

Para gerar o artefato (um JAR neste caso), o comando seria o seguinte (mai s d ownl oad s ;-):

$ mvn package

O comando acima gerará um artefato cujo nome será composto pelos elementos definidosno pom.xml utilizando o padrão artifactId-version.packaging. Ou seja, neste caso, o artefatogerado será teste-1.0-SNAPSHOT.jar. Este arquivo fica disponível no diretório target, comodemonstrado abaixo:

$ tree -a

. pom.xml src main java com ladoservidor App.java test java com ladoservidor AppTest.java target

classes com

ladoservidor App.class maven-archiver pom.properties surefire-reports com.ladoservidor.AppTest.txt TEST-com.ladoservidor.AppTest.xml test-classes com ladoservidor AppTest.class teste-1.0-SNAPSHOT.jar

18 directories, 9 files

Para que este artefato possa ser utilizado por algum outro, que o tenha como dependência, ele deverá estar instalado. A instalação pode ocorrer em dois locais diferentes: o primeiro deles, é o repositório local. Quando umartefato é implantado neste repositório, o desenvolvedor que o implantou pode utilizá-lo mas, nenhum outrodesenvolvedor terá como também utilizar este artefato a não ser que o implante em seu próprio repositório. É aíentão que surge a necessidade de um repositório remoto (e compartilhado) que possa ser utilizado por todos osdesenvolvedores. Mai s a f rent e, nest e t utorial, iremos ut ilizar o Nexus para criar e gerenciar est e t i po dere posi tóri o (remoto e c om par t il had o ).

A instalação de um artefato no repositório local pode ser realizada através do seguinte comando (mai s

d ownl oad s serão realizad os ):

$ mvn install



O processo de instalação geralmente solicita que antes sejam executados os testes e, por fim, o pacote écopiado para o repositório local, conforme pode ser notado pela saída do comando acima.

Como nosso artefato foi configurado com o valor ladoservidor para o elemento groupId noarquivo pom.xml, em nosso repositório local haverá um diretório ladoservidor que irá conter o JARinstalado. Observe a árvore criada pelo maven a partir deste diretório:

$ tree ~/.m2/repository/ladoservidor//home/negocios/.m2/repository/ladoservidor/ teste

1.0-SNAPSHOT maven-metadata-local.xml teste-1.0-SNAPSHOT.jar teste-1.0-SNAPSHOT.pom maven-metadata-local.xml

A árvore acima é organizada utilizando-se os valores dos elementos groupId/artifactId/versionId.

Uma vez instalado, outro artefato que tivesse este como dependência, poderia então utilizá-lo. Além disto, apósa instalação, talvez você queira apagar os arquivos produzidos no ato da construção do artefato. É fácil fazer isto simplesmente executando o comando abaixo (mai s d ownl oad s serão realizad os ):

$ mvn clean

O comando acima removerá o diretório target que contém tudo o que é gerado pela solicitação do Maven.

Como o Maven executa os comandos acima? Porque ele faz tantos downloads? A resposta a estas questões: oMaven é extremamente modular. Quando o instalamos, ele só possu i aquilo que é necessário para fazer odownload de todo o resto. O Maven é fortemente baseado no conceito de plugins que são configurados noarquivo pom.xml para o uso pelo projeto. Os plugins do maven são, de certa forma, equivalentes a targetsdo Ant. São eles que executam várias tarefas, realizadas por fases no processo de construção. Além de muitasvezes estes plugins não estarem presentes, e ser necessário o seu download para a execução de tarefassolicitadas em uma linha de comando, o Maven também baixará todas as dependências que um artefatoprecisar para instalá-las no repositório local.

Uma vez instalados os plugins, eles ficarão permanentemente disponíveis e versionados no repositório local dousuário. Eles só sairiam de lá caso o usuário excluísse o repositório. Sendo assim, caso solicitássemos a re-execução dos comandos deste tópico, nenhum download seria realizado novamente. Podemos testar istorealizando a execução do comandos a seguir:

$ mvn compile test package install clean

Se observarmos cuidadosamente o log de saída do comando acima, poderemos notar que a execução doTestCase com.ladoservidor.AppTestfoi realizada três vezes. Isto ocorre pelo fato de, ao executarmosos comandos test, package e install, estarmos executando fases. A fase test solicita, obviamente, aexecução de testes. Mas, a fasepackage é uma fase que depende da execução dos testes e, por consequência, é executada novamente. O mesmo ocorre para a fase install. É por isto que a execuçãoocorre repetidamente. Logo, o correto, quando queríamos repetir as fases executadas pelos vários comandosanteriores em uma só linha, seria executarmos apenas as seguintes instruções:

$ mvn install clean

Como talvez tenha sido notado, o Maven trabalha com o conceito de "convenções ao invés de configurações".Por exemplo, é uma convenção a estrutura de diretórios utilizada para o armazenamento dos arquivos. Casodesejássemos outra, poderíamos tê-la, mas também necessecitaríamos de configurações para isto. O conceitode "convenções ao invés de configurações" é chave no Maven e é amplamente adotado em diversos aspectos,tornando a ferramenta ainda mais simples de ser utilizada.

Gerando Um Projeto Web Que Utiliza O Framework Wicket



Vamos agora gerar outro projeto (artefato) que será uma aplicação Web. Para tornar as coisas um pouco m aisdivertidas esta aplicação utilizará o framework Apache Wicket. Mais a f rente neste tutorial, iremos tornar aconstrução desta aplicação dependente do artefato (projeto) JAR gerado no tópico anterior.

Iremos gerar a aplicação Wicket no $HOME do usuário web utilizando também um arc hetype. Sendo assim,abriremos um novo shell e executaremos os comandos seguir:

$ sudo su - web$ mvn archetype:generate -DinteractiveMode=false \-DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.4.9 \-DgroupId=com.ladoservidor -DartifactId=teste-wicket -Dversion=1.0-SNAPSHOT

Alguns detalhes que precisamos notar na geração do projeto, pela execução do comando acima:

y O diretório do projeto foi especificado pela propriedade -Dar t i f ac tI d=t est e-w icket ;

y O Maven não fez nenhuma pergunta (-Di nt erac t iveM ode=f al se);

y O tipo do archetype foi especificado por -Darc hetypeAr t i f ac tI d=w icket -arc hetype-quick st ar t ;

y Os parâmetros para a formação do POM também foram todos passsados na linha de comando;

A estrutura de diretórios que foi montada é apresentada a seguir:

$ cd teste-wicket && tree -a. pom.xml src

main java com ladoservidor HomePage.html HomePage.java WicketApplication.java resources log4j.properties webapp WEB-INF web.xml test

java com

ladoservidor Start.java TestHomePage.java

Para executar esta aplicação web, o pom.xml gerado por este arc hetype já possui todas as informaçõesnecessárias para o trabalho com o plugin jetty, que é sobe um w eb c ont ai ner e implanta automaticamente oartefato gerado (no caso, um arquivo WAR).

Compreendendo Alguns Detalhes No Pom.Xml Do Projeto Web

Vamos nos ater a alguns detalhes do pom.xml para o projeto gerado. Como este é apenas uma tutorialintrodutório, não iremos explorar todos os vários recursos de configuração do Maven mas, apresentaremosalguns deles.

As linhas de 4 a 7 do pom.xml apresentam os atributos essenciais do POM. Observe que o tipo deempacotamento agora é diferente (produz um arquivo W AR):

$ sed -n '4,7p' pom.xml<groupId>com.ladoservidor</groupId><artifactId>teste-wicket</artifactId><packaging>war</packaging>



<version>1.0-SNAPSHOT</version>

Na execução do comando abaixo, apresentamos as linhas que configuram a dependência JUnit. O detalhe aquié o elemento scope indicando que a dependência junit só é necessária quando o Maven for realizar testes daaplicação.

$ sed -n '47,53p' pom.xml

<dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>3.8.2</version><scope>test</scope>

</dependency>

Também é interessante notar as configurações para as dependências do Jetty, que executa a aplicação. Comoos JARs necessários para a execução do mesmo já estão implantados neste c ont ai ner , não faz sentido que elestambém sejam colocados no diretório WEB-INF/lib do WAR que será gerado. Logo, oelemento scope configurado para as dependências relativas aos JARs, neste caso, é to tipo provided. Istopode ser exemplificado pelo trecho de código a seguir:

$ sed -n '56,61p' pom.xml<dependency><groupId>org.mortbay.jetty</groupId><artifactId>jetty</artifactId><version>${jetty.version}</version><scope>provided</scope>

</dependency>

O resultado do sed executado acima também demonstra que a versão do artefato jetty é configurada através deuma propriedade. O seu valor pode ser obtido através da configuração do elemento properties:

$ sed -n '129,132p' pom.xml<properties><wicket.version>1.4.9</wicket.version><jetty.version>6.1.4</jetty.version>

</properties>

Para implantar e executar a aplicação no Jetty, o pom.xml precisa conter a configuração para o uso do plugin jetty. Isto é informado nas linhas abaixo, que estão configuradas como parte do elemento plugins:

$ sed -n '116,119p' pom.xml<plugin><groupId>org.mortbay.jetty</groupId><artifactId>maven-jetty-plugin</artifactId>

</plugin>

Além destes, vários outros detalhes de configuração também poderiam ser explorados aqui, mas vamos seguir em frente.

Executando A Aplicação Web

Para mandar executar a aplicação o comando é simples:

$ mvn install jetty:run

A parte ruim desta história: todos os downloads que já haviam sido realizados anteriormente na conta dousuário negocios foram refeitos pelo usuário web:-(.

A execução do comando acima na realidade cuida de várias tarefas:



y install: Compila, testa e instala o artefato (WAR) no repositório local;

y jetty:run: Inicia o Jetty e solicita que ele implante o artefato preparando-o para a execução;

Com a aplicação sendo executada, podemos agora, acessá-la no browser através daURL http://localhost:8080/teste-wicket. Esta aplicação não faz nada além do que qualquer outra aplicação dotipo "Hello World" faria mas, nós iremos atualizá-la para entender o mecanismo de de pl oy utilizado pelo Maven.Para interrromper sua execução, iremos na console que está executando o comando teclaremos <Ctrl-C>.

Vendo A Árvore De Dependências Da Aplicação Web

Como este projeto (artefato WAR) possui várias dependências, se desejássemos imprimir a árvore dasdependências, poderíamos executar o comando a seguir e observar sua saída(mai s d ownl oad s :-():

$ mvn dependency:tree | sed -n '/Building/,/BUILD/p'[INFO] Building quickstart 1.0-SNAPSHOT[INFO] ------------------------------------------------------------------------[INFO][INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ teste-wicket ---[INFO] com.ladoservidor:teste-wicket:war:1.0-SNAPSHOT[INFO] +- org.apache.wicket:wicket:jar:1.4.9:compile[INFO] | \- org.slf4j:slf4j-api:jar:1.5.8:compile[INFO] +- org.slf4j:slf4j-log4j12:jar:1.4.2:compile[INFO] +- log4j:log4j:jar:1.2.14:compile[INFO] +- junit:junit:jar:3.8.2:test[INFO] +- org.mortbay.jetty:jetty:jar:6.1.4:provided[INFO] | \- org.mortbay.jetty:servlet-api-2.5:jar:6.1.4:provided[INFO] +- org.mortbay.jetty:jetty-util:jar:6.1.4:provided[INFO] \- org.mortbay.jetty:jetty-management:jar:6.1.4:provided[INFO] +- mx4j:mx4j:jar:3.0.1:provided[INFO] \- mx4j:mx4j-tools:jar:3.0.1:provided[INFO] ------------------------------------------------------------------------[INFO] BUILD SUCCESS

Note que cada linha da árvore de dependências é apresentada no seguinteformato: groupId:artifactId:packaging:version:scope. Esta saída apresenta toda a informação

necessária para se obter os detalhes de que artefatos são necessários em cada estágio (escopo) do processode contrução/implantação de um artefato.

Uma Introdução Ao Nexus

Motivando O Uso Do Nexus

O Nexus é um gereciador de repositórios para o Maven.

Gerenciadores de repositórios tem dois propósitos primordiais:

y Atuar como proxies altamente configuráveis entre uma organização e os repositórios públicos doMaven;

y Suprir uma organização com um destino para a publicação de seus próprios artefatos;

Atuando como proxy para repositórios públicos, o Nexus reduz significativamente a quantidade de downloadsreduntantes pelos elementos da organização, evitando chamadas externas a Internet e diminuindo o tempogasto internamente, para o download de artefatos. Isto reduz, consideravelmente, o tempo para a construção deaplicações.

Instalando O Nexus



Tal

¡ ¢

£

¡ ¤ ¡ j ¡

¥

¦ ¤

¡

§ ¦ í£

¡ ¦ ¨ §

¦

£

© ¢ i

£

¦ ̈

¡ la ¨ §

¨ § ia S¦ at

̈

¡ f alando da instalação do

¡

© s.

as, omo o ¨ §

ocesso §

ealmente muito simples, os passos são apenas os

ue estão publicados abai

o:

Vamos instalar o nexus, inicialmente em seu própr io $HOME. Para isto,

amos iniciar um terceiro shell, cr iar e nos logar com um novo usuár io:

$ sudo useradd -m -s /bin/bash nexus

$ sudo su - nexus

Agora, vamos f azer o seu download e descompactação:

$ wget -c http://nexus.sonatype.org/downloads/nexus-oss-webapp-1.7.0-bundle.tar.gz$ tar xvfz nexus-oss-webapp-1.7.0-bundle.tar.gz

Ao descompactar o instalador do nexus, serão gerados dois diretór ios:nexus-oss-webapp-1.7.0 e sonatype-work. pr imeiro armazena os binár ios de execução do

exus. Isto assim para f acilitar o upgrade de uma versão do nexus de f orma a não ser necessár ia a maninulação do seu diretór io de dados.

Agora estamos preparados para iniciar o

exus em modo console mostrando o log de sua execução):

$ cd nexus-oss-webapp-1.7.0$ ./bin/jsw/linux-x86-32/nexus console

Após o servidor ter iniciado, podemos acessar a !

"

#

http://localhost: $

%

$ & /nexus

ue apresenta a inter f ace administrativa do

exus. A tela inicial mostrada abaixo. bserve

ue ao lado esquerdo da tela, quando clicamos no link

' " epositor ies" podemos observar uma lista de repositór ios já cadastrados e gerenciados pelo

exus.!

m repositór io um local aonde os ar tef atos consumidos ou produzidos pelo

aven serão armazenados.

a tela que apresenta os repositór ios, podemos notar a presença de alguns tipos de repositór ios: group,hosted, proxy e virtual.

Um repositór io do tipo proxy (

um repositór io externo em que o )

exus busca os ar tef atos e os publica em sua base local. Um repositór io do tipohosted

(

interno, ou se ja, os ar tef atos que são publicados neste repositór io não são obtidos de nenhuma f onte externa. Um repositór io do tipo group

(

, na verdade, um agrupamento de repositór ios.

)

o 0 aven, uma aplicação pode depender de dois tipos de ar tef atos: S)

APS 1

2

TS e 3 E4

EASES. Um S

)

APS1

2

T geralmete (

um ar tef ato que não está marcado 5

tagead 6 ) em um sistema de controle de versões.Um

7

E8 EASE, por sua vez, 9 um ar tef ato que já pode ser considerado maduro @

estável) e que geralmente já está tagead 6 num SCM . A B exus gerencia e armazena estes dois tipos de ar tef atos, produzidos por uma organização qualquer .

AlteC D n

E F As

G F nf

H I u

C D P ões

Q F

R

D

S enT D C D

U ue V le W se X Nexus

Para que o Y aven possa atuar com o ̀

exus em seus dois propósitos pr imordiais ele precisa ter seu arquivo de configuração

a

settings.xml) a justado. Isto pode ser realizado para um usuár io específico b ~/.m2/settings.xml) ou para todos os usuár ios b

$M2_HOME/conf/settings.xml).c

omo neste



tutorial o Maven está sendo utilizado por dois usuários (negocios e web) iremos criar um arquivo deconfigurações ao nível de instalação do Maven. Para isto, abra um quarto shell e execute o comando a seguir:

$ sudo bash -c 'cat > /opt/maven/conf/settings.xml <<EOF<settings><mirrors><mirror><id>nexus</id><mirrorOf>*</mirrorOf><url>http://localhost:8081/nexus/content/groups/public</url>

</mirror></mirrors><profiles><profile><id>nexus</id><repositories><repository><id>central</id><url>http://central</url><releases><enabled>true</enabled></releases><snapshots><enabled>true</enabled></snapshots>

</repository></repositories><pluginRepositories>

<pluginRepository><id>central</id><url>http://central</url><releases><enabled>true</enabled></releases><snapshots><enabled>true</enabled></snapshots>

</pluginRepository></pluginRepositories>

</profile></profiles><activeProfiles><activeProfile>nexus</activeProfile>

</activeProfiles></settings>EOF'

A partir de agora, todo e qualquer download que for realizado será feito através do Nexus, tendo como base aURL especificada no arquivo $M2_HOME/conf/settings.xml. Sendo assim, quando outro qualquer outrodesenvolvedor da corporação for utilizar o Maven (configurando $M2_HOME p/ /opt/maven), caso os artefatos jáestejam armazenados no cache deste gerenciador, não haverá mais a necessidade de novas requisições HTTPpara a Internet, a fim de realizar o download dos mesmos artefatos.

Uma boa experiência, que enche os olhos de qualquer novo utilizador de um gerenciador de repositórios, éapagar os artefatos armazenados em repositório local para testar a velocidade de um novo download dosmesmos após a instalação do gerenciador. Vamos experrimentar isto!

Indo ao shell aberto para o usuário web, iremos apagar o seu repositório local e a seguir, mandaremosreexecutar a aplicação:

$ rm -rf ~/.m2/repository$ mvn install jetty:run

Podemos notar que agora todo o download está sendo realizado pela URL local do gerenciador de repositóriosdo Nexus, ao invés de através da Internet. Como o Nexus está atuando como proxy, todos artefatos estãosendo colocados em seu cache. Em seguida, o Maven faz a cópia do artefato para repositório local do usuário.Desta forma podemos saber que, se apagarmos outra vez o rep ositório local, todos os artefatos baixados



anter iormente estarão no cache do nexus e, consequentemente, não haverá download de ar tef atos a par tir da Internet tornando a montagem do repositór io local extremamente mais rápida!

A configuração f eita acima, no arquivo settings.xml, habilitará o d aven a trabalhar com um repositór io do tipo group, que

e

um agrupamento de alguns repositór ios onde, ale

m de podermos f azer o download de ar tef atos de repositór ios públicos prox i ad os pelo f exus, também podemos publicar snapshots e releases.

f a configuração apresentada, f oi definido o uso de um único profile:nexus. Este profile está configurado para o download a par tir de um repositór io central através de uma URL f alsa g http://central). Esta URL é sobrescr ita nas configurações do

h

exus e aponta para um repositór io do tipo group. Ao final do arquivo está explícito, através do elementoactiveProfiles, que este profile está ativo.

Para entender um pouco melhor o que é este grupo configurado no h

exus e que é acessível através da URL http://localhost: i

p

i q /nexus/content/groups/public, vamos nos logar no

h

exus para ver como este grupo está configurado. Para f azer o login, o usuár io/senha que devem ser inf ormadas são admin/admin123. Após o l og on, vamos clicar no repositór io "Public Repositor ies" pois é ele que está configurado para aRepositoryPath com a URL inf ormada no arquivo ~/.m2/settings.xml. r ote que aparecerá a aba "Configuration" na par te inf er ior da página.

Através desta configuração podemos notar que o identificador do grupo s

Group ID) configurado no arquivo ~/.m2/settings.xml com o nome public representa um grupo cu ja a ordem de busca dos ar tef atos é listada no campo "Ordered t roup Repositor ies". Ve ja que neste campo, são listados vár ios outros

repositór ios configurados no r

exus.

Alte n eto e Ge o In lmente

Vamos alterar o pro jeto u eb para que ele utilize o pro jeto de negócios como dependência. A alteração será muito simples: ao invés de impr imir a mensagem padrão apresentada pela aplicação em sua página pr incipal " If .* runni ng " , queremos que se ja impresso o conteúdo da constante MESSAGE que será declarada na classe de negócios com.ladoservidor.App.

Vamos realizar esta mudança guiando-nos pelos testes. Ou se ja, vamos praticar T est v r i w en v evel opment

x TDD). Então, iniciaremos nossas mudanças pela classecom.ladoservidor.TestHomePage. O comando a seguir altera a linha y

�

desta classe � ava para o seu novo conteúdo �

de acordo com o requisito):

$ sed -i '28s/"If.*running"/com.ladoservidor.App.MESSAGE/'

src/test/java/com/ladoservidor/TestHomePage.java

Com esta mudança, o código da classe de testes agora dependerá da classe de negócios com.ladoservidor.App. Também f aremos a mudança necessár ia no código da classecom.ladoservidor.HomePage, na linha y 5:

$ sed -i '25s/"If.*running"/com.ladoservidor.App.MESSAGE/'src/main/java/com/ladoservidor/HomePage.java



Como agora o projeto depende da classe com.ladoservidor.App, precisaremos informar o JAR quecontém esta dependência no arquivo pom.xml. Isto pode ser realizado através do seguinte comando:

$ sed -i '/<dependencies>/ a\\t\t\\t\t<dependency>\\t\t\t<groupId>ladoservidor</groupId>\\t\t\t<artifactId>teste</artifactId>\\t\t\t<version>1.0-SNAPSHOT</version>\\t\t</dependency>' pom.xml

Não vai dar para compilar a aplicação Web pois ela passou a depender de um pacote que ainda não estáinstalado no repositório local do usuárioweb. A fim de instalá-lo, poderíamos pedir ao usuário negocios para,após efetuar as mudanças necessárias, gerar e nos enviar o pacote para que pudessemos instalá-lo via "mvninstall". O problema desta abordagem é que ele é muito manual! A alternativa automática (e mais correta)seria o usuário negocios gerar o pacote e implantá-lo em um repositório remoto e compartilhado. Desta forma,com as configurações de acesso a este repositório realizadas pelo usuárioweb, ele poderia baixar o pacotedeste repositório remoto e instalá-lo localmente. Sendo assim, estes serão os próximos passos apresentados.

Alterando O Projeto NegóciosG

erado InicialmenteVamos alterar o projeto de negócios (que gera o JAR) para que ele contenha a constante que é utilizada peloprojeto Web.

Voltando ao shell aberto para a execução dos comandos do usuário negocios, vamos alterar oprojeto testes, adicionando a linha que declara a constanteMESSAGE na classecom.ladoservidor.App:

$ sed -i '8 a\public static final String MESSAGE = "Hello World!";

' src/main/java/com/ladoservidor/App.java

Efetuando O Deploy Do Projeto De Negócios

Vamos efetuar a implantação do projeto de negócios para torná-lo disponível para uso do projeto Web.

O comando para isto é apesentado abaixo. Tentando execuá-lo, obtemos um erro do Maven informando que oprojeto ainda não foi configurado adequadamente para que o deploy possa ser relizado. A diferença básicaentre o comando "mvn install"e o comando "mvn deploy"é o tipo de instalação executada. Noprimeiro caso, a instalação do artefato é no repositório local (con hecidamente ~/.m2/repository). Nosegundo, a instalação é realizada num r epostiório remoto que precisa estar configurado!

$ mvn deploy

Obviamente, o nosso próximo passo então, é configurar o pom.xml informando a localização deste repositórioremoto! O comando a seguir realiza esta tarefa alterando o arquivo pom.xml adequadamente:

$ sed -i '/<\/dependencies>/ a\<distributionManagement>\<repository>\<id>releases</id>\<url>http://localhost:8081/nexus/content/repositories/releases</url>\

</repository>\<snapshotRepository>\<id>snapshots</id>\<name>Internal Snapshots</name>\<url>http://localhost:8081/nexus/content/repositories/snapshots</url>\

</snapshotRepository>\



</distributionManagement>' pom.xml

Fazendo as alterações acima, estamos agregando duas informações ao projeto:

y Os releases gerados serão publicados no repositório cujo id é releases;

y Os snapshots gerados serão publicados no repositório cujoid é snapshots;

Cada um dos repositórios também tem a sua URL de acesso para o download de artefatos configurada nestearquivo.

Somente as informações acima não bastam, pois, caso seja reexecutado o comando "mvn deploy" iremostomar um erro de autenticação na publicação dos artefatos gerados no repositório remoto! Então, para nãotermos este problema, será necessária também a cofiguração do arquivo ~/.m2/settings.xml. Como serácriado o arquivo settings.xml especificamente para o usuário negocios, o seu conteúdo será gerado atravésdo comando a seguir:

$ cat > ~/.m2/settings.xml <<EOF<?xml version="1.0" encoding="UTF-8"?><settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0http://maven.apache.org/xsd/settings-1.0.0.xsd"><servers><server><id>snapshots</id><username>deployment</username><password>deployment123</password>

</server><server><id>releases</id><username>deployment</username><password>deployment123</password>

</server><server><id>thirdparty</id><username>deployment</username>

<password>deployment123</password></server></servers>

</settings>EOF

Após realizada a configuração acima, a cada nova execução do comando abaixo será gerado um sna pshot norepositório remoto. Este sna pshot poderá então ser baixado pelo Maven quando outro artefato depender de suautilização. A próxima parte deste tutorial apresenta maiores detalhes sobre como um sna pshot é armazenado norepositório remoto e as diferenças com relação a um release.

$ mvn deploy

Finalizando A Construção Do Projeto WebVoltando ao shell da aplicação Web, podemos agora solicitar que ela seja construída pelo maven e executadapelo Jetty. Para fazer isto:

$ mvn install jetty:run

O comando acima irá baixar o sna pshot gerado pelo usuário negocios e instalá-lo no repositório local paraque a aplicação possa então ser compilada com sucesso. Quando em execução pelo Jetty, a aplicação poderánovamente ser acesssada pela URL http://localhost:8080/teste-wicket. Agora, a tela deverá apresentar amensagem "Hello World".

Documents

Utilizando Maven Nexus e Subversion 1