2 INTRODUÇÃO. Construindo aplicações jcompany com Maven

(1)

1 CONTEÚDO

1 Conteúdo ... 1

2 Introdução ... 2

3 Fundamentos Básicos do Maven ... 3

3.1 Estrutura de diretórios e ciclo de execução ... 3

3.2 Repositórios ... 5

4 Introdução às configurações do maven ... 6

4.1 Dependências ... 8

4.2 Depedências de módulos Visão ... 9

4.3 Dependências externas ... 11

4.3.1 Empresas sem repositório interno ... 11

4.3.2 Jars que não encontram-se no repositório público ... 11

4.3.3 Adicionando um artefato ao repositório da empresa ... 11

4.4 Publicado o projeto no repositório da empresa ... 12

5 Comandos básicos ... 13

5.1 Instalando o projeto no repositório local ... 13

5.2 Instalando no repositório remoto da empresa ... 13

5.3 Fazendo deploy no servidor de aplicação ... 13

5.4 Fazendo deploy Rápido para o servidor ... 14

5.5 Fazendo deploy rápido com reinicialização ... 14

5.6 Fazendo deploy para produção ... 14

6 Configurando a máquina do desenvolvedor ... 15

7 Repositório Interno da empresa ... 17

7.1 Como Instalar um proxy para a empresa ... 17

7.2 Configurações Básicas ... 17

7.3 Configurações de proxy ... 17

7.4 Configurar os repositórios Públicos ... 18

7.5 Inicializando o proxy ... 18

7.5.1 Windows ... 18

7.5.2 Linux ... 18

7.6 Verificando a instalação... 19

(2)

2 INTRODUÇÃO

O Maven foi bastante personalizado para atender as necessidades do framework jCompany, principalmente porque o suporte do Maven a projetos com muitos módulos, e módulos

reutilizáveis não é muito bom. Portanto nesse manual será explicado mais a fundo como utilizar o Maven com o jCompany e não entraremos em detalhes de personalização do Maven.

(3)

3 FUNDAMENTOS BÁSICOS DO MAVEN

3.1 ESTRUTURA DE DIRETÓRIOS E CICLO DE EXECUÇÃO

Cada módulo da aplicação tem a seguinte estrutura de diretórios.

FIGURA 1

Cada tipo de arquivo tem um local especifico porque o Maven copiará e transformará esses arquivos para diferentes locais no Servidor (Tomcat). Segue abaixo a tabela de diretórios e os respectivos locais onde serão colocados os arquivos após o deploy.

Diretório Descrição Local no Servidor

/src/main Local onde ficam os contextos do Tomcat no formato : NOME_PROJETO_prod_context.xml - PRODUÇÃO NOME_PROJETO_teste_context.xml - TESTE NOME_PROJETO.xml - DESENVOLVIMENTO

Os arquivos de contextos serão copiados no reinicializacao e no plc:deploy-completo $CATALINA_HOME/c onf/Catalina/localhos t/NOME_PROJETO.xm l

/src/main/java Arquivos Java que devem ser compilados. /WEB-INF/classes

/src/main/resources Arquivos devem ser colocados no path da

aplicação /WEB-INF/classes

/src/main/webapps Arquivos gerais como .jsp, .css o diretório

/WEB-INF ... Será copiado para a raiz da aplicação

/src/test/java Arquivos do jUnit e jWebUnit -

/src/test/resources Não utilizado. Serão usados os arquivos de

resources do /src/main/resources -

O Maven tem um ciclo de execução. Isso significa que o POM (arquivos de configuração do build) não é executado de forma procedural. Podem-se escolher diferentes fases para execução e cada fase executará diversas tarefas já definidas. As fases de um projeto do tipo war é:

process-resources – Copia os arquivos de /src/main/webapps e

/src/main/resources para um diretório temporário utilizado montagem do build. Esse diretório encontra-se em ../maven_target/NOME_PROJETO.

(4)

process-test-resources – Copia os arquivo /src/test/resources para o diretório temporário.

test-compile – Compila os arquivos java de teste que ficam em /src/test/java para o diretório temporário.

test – Executa os testes jUnit

package – Compacta os arquivos que do diretório temporário, excluindo os arquivos de teste gerando um arquivo com extensão do tipo <packaging> no arquivo de

configuração do projeto.

install – Copia o artefato final do build para o repositório local. deploy – Copia o artefato final do build para o repositório remoto. Cada fase executa sua tarefa e as tarefas anteriores.

Exemplo: Se executado o Maven em um projeto com o comando mvn test o maven executará as fases process-resources, compile, process-test-resources, test-compile e test.

Também é possível a execução de tarefas especificas sem utilizar alguma fase.

Exemplo: Se executado o Maven em um projeto com o comando mvn jar:jar o Maven apenas compactará o que esta dentro do diretório target. Assim será executada a compactação do projeto, mas não garante que serão colocado os arquivos .java compilados.

Nesse ciclo b|sico foram “coladas” duas tarefas a fase “process-resources”

1. unpack – Descompacta os arquivos dependentes do tipo War dentro do diretório target. Será explicado mais adiante o porquê dessa tarefa.

2. add-sourcepath – Adiciona o diretório /src/main/config no classpath para compilação, porque o padrão é somente o diretório /src/main/java.

A Powerlogic desenvolveu 3 tarefas que n~o s~o “coladas” { nenhuma fase, s~o elas: plc:deploy-completo – Pega o arquivo war da aplicação, descompacta dentro de

$CATALINA_HOME/webapps/NOME_PROJETO e copia o contexto para o local adequado no servidor.

plc:deploy-rapido – Copia os arquivos MODIFICADOS de todos os módulos que estão sob os diretórios /src/main/webapps

plc:deploy-reinicializacao – Copia os arquivos /src/main/webapps, compacta os arquivos .class criados pelo Eclipse nos MODULOS com <packaging>jar</packaging> e copia os arquivos .class dos módulos Visão e do modulo principal para o Server. Copia o contexto para o Server também, o que força o servidor a ser reinicializado.

Ao analisarmos o comportamento dessas tarefas podemos chegar às conclusões:

O plc:deploy-completo deve ser executado apenas quando já existir o .war pronto. Por isso é aconselhável que antes de executá-lo seja executado a fase package quando não tiver outros módulos ou install quando for um projeto multi-modulo, para gerar o war completo! O uso básico indicado seria então utilizar install plc:deploy-completo O deploy-rapido não precisa de nenhuma tarefa anterior.

O deploy-reinicialização só será útil possível se o Eclipse estiver gerando as .class automaticamente. Por padrão o Eclipse já faz isso.

(5)

3.2 REPOSITÓRIOS

Um repositório serve para armazenar artefatos de build e uma variedade de dependências. Basicamente existe apenas dois tipos de repositórios, local e remoto. O local é um cachê do repositório remoto e contêm os builds temporários que ainda n~o foram “released”. O jCompany instala automaticamente um repositório local completo, não sendo necessário o acesso remoto à repositórios remotos na grande maioria das vezes.

O repositório local é instalado no diretório $JCOMPANY_INSTALL/repositório. Para a organização dos artefatos no repositório é definido um padrão:

$REPOSITORIO\groupId\artifactId\version\artifactId-version.*

Assim ao executar o comando install no projeto o Maven pegará o artefato final que pode ser um jar, war, .*, e copia para o repositório respeitando o padrão acima, modificando inclusive o nome do próprio arquivo.

Pode ser feita uma analogia entre o groupId do Maven com o package do java. ArtifacId é o nome do projeto.

Exemplo:

Se tivermos um projeto aqui na Powerlogic com as seguintes configurações: groupId – com.powerlogic

artifactId – MeuProjeto version – 1.0

Executando o Maven com a fase install no projeto será criado o arquivo

(6)

4 INTRODUÇÃO ÀS CONFIGURAÇÕES DO MAVEN

As configurações do Maven são hierarquizadas, pode-se fazer uma analogia a orientação a objetos. Assim temos uma “Super Classe” que contém todas as dependências do framework jCompany. Essa “Super Classe” no Maven é o artefato powerlogic.jcompany.projeto-plc. Todos os projetos que utilizam o jCompany devem estender esse artefato. Como o projeto pode ter diversos módulos, outra “classe” (pom) deve ser criada. Esse pom estender| o jCompany e cada módulo ser| uma “classe” (pom) que estenderá do mesmo. A hierarquia ficaria como no

esquema abaixo:

Para utilizar o jCompany, edite o arquivo “projeto-pom.xml” no módulo principal da aplicação da seguinte forma:

<groupId>powerlogic.jcompany</groupId> <artifactId>projeto-plc</artifactId>

Configure no projeto-pom.xml o groupId do projeto, artifactId , version e name da aplicação:

Para facilitar o entendimento das configurações utilizaremos um projeto fictício chamado ERP como exemplo. Esse projeto tem três módulos: o módulo ERP que será o módulo principal, o

pom.xml

projeto-pom.xml

pom.xml

powerlogic.jcompany.projeto-plc empresa.MeuProjetoParent empresa.modulo1 empresa.modulo2

(7)

módulo financeiro, e o módulo RH. Assim o projeto-pom.xml ficará dentro do módulo considerado o principal. No nosso exemplo o módulo principal é o módulo ERP.

Dentro do arquivo projeto-pom.xml configuramos o groupId, artifactId, version, name e packaging: <groupId>empresa.exemplo</groupId> <artifactId>projeto-ERP</artifactId> <version>1.0</version> <name>Projeto ERP</name> <packaging>pom</packaging>

O packaging define qual a finalidade do pom e pode ser do tipo pom, jar ou war.

O projeto-pom.xml tem como finalidade configurar outros módulos portando será do tipo pom. Se o pom for a configuração de um módulo que gerará um jar coloque o tipo jar e se for para gerar um war coloque war. Os projetos do tipo war normalmente são os módulos Visão da aplicação e o módulo principal!

No arquivo projeto-pom.xml também é configurado quais módulos devem ser construídos ou reconstruídos ao fazer o build da aplicação. Para isso adicione a configuração:

<module>../erp-financeiro</module> <module>../erp-rh</module>

<module>../erp-principal</module> </modules>

Dentro da tag “module” coloque o endereço (diretório) do módulo. O Maven julga que o pom parent sempre esteja um diretório abaixo dos módulos como mostrado abaixo:

/erp-financeiro pom.xml /erp-Rh pom.xml /erp-principal pom.xml pom.xml

Mas dessa forma torna-se difícil de reutilizar os módulos quando colocados em um controle versão. Com isso foi adotado o seguinte padrão:

/erp-financeiro pom.xml /erp-Rh

(8)

/erp-principal pom.xml

projeto-pom.xml

Com isso as configurações dos “modules” devem ter “../” antes do diretório do módulo.

Agora edite o arquivo pom.xml do módulo erp-principal para estender o módulo pai no caso o projeto-pom.xml. <parent> <groupId>empresa.exemplo</groupId> <artifactId>projeto-ERP</artifactId> <version>1.0</version> <relativePath>projeto-pom.xml</relativePath> </parent>

Automaticamente o Maven tentará localizar o arquivo pom.xml definido na tag “parent” um diretório acima. Como o nosso “parent” esta dentro do nosso módulo principal, precisamos adicionar a tag “relativePath” com o nome do pom ancestral.

Nos outros módulos repita o trecho acima, mas substituindo o “relativePath” para

<relativePath>../erp-principal/projeto-pom.xml</relativePath>

4.1 DEPENDÊNCIAS

Em nosso exemplo os módulos têm dependências entre si da seguinte forma.

O módulo erp-rh necessita do módulo erp-financeiro. O módulo erp-principal necessita dos outros dois módulos.

Para definir as dependências adicione o código no pom.xml de cada module:

“type” é o packaging do artefato que está sendo adicionado. Pode ser jar ou war. Se omitido será considerado como “jar”.

(9)

“compile” colocará a dependência dentro do novo artefato gerado e colocado no classpath para compilação. Se o novo artefato gerado for um war, como todas as aplicações jCompany, o Maven colocará essa dependência dentro de /WEB-INF/lib. “runtime” colocar| a dependência dentro do novo artefato gerado, mas não será colocado no classpath ao compilar o projeto.

“provided” colocado no classpath da aplicaç~o ao compilar, mas n~o coloca a dependência dentro no novo artefato gerado.

OBS: Todas as dependências do tipo war devem ter “scope” provided. Isso porque não queremos que o arquivo war seja colocado dentro de /WEB-INF/lib da nova aplicação. Mais adiante discutiremos como lidar com dependências War.

Voltando ao nosso exemplo, teremos que colocar a dependência erp-financeiro dentro do pom.xml do módulo erp-rh:

<dependencies> <dependency> <groupId>empresa.exemplo</groupId> <artifactId>erp-financeiro</artifactId> <version>1.0</version> </dependency> </dependencies>

E dentro do módulo principal(pom.xml) precisamos declarar sua dependência com o erp-finaceiro e erp-principal: <dependencies> <dependency> <groupId>empresa.exemplo</groupId> <artifactId>erp-financeiro</artifactId> <version>1.0</version> </dependency> <dependency> <groupId>empresa.exemplo</groupId> <artifactId>erp-rh</artifactId> <version>1.0</version> </dependency> </dependencies>

4.2 DEPEDÊNCIAS DE MÓDULOS VISÃO

Ao nosso projeto ERP adicionaremos mais um módulo, erp-visao. Para isso adicionaremos dentro do arquivo projeto-pom.xml que se encontra no módulo erp-principal uma nova entrar na tag “modules”

(10)

<module>../erp-visao</module>

Assim todas às vezes que forem dadas o comando para construir a aplicação esse módulo será reconstruído ou verificado por mudanças de arquivos quando em deploys rápidos.

O módulo do tipo war (exceto o módulo principal) não deve herdar do projeto-pom.xml porque se herdado será colocado todos os jar do jCompany dentro de /WEB-INF/lib do módulo visão e isso não é necessário. O módulo principal é o encarregado de adicionar todas as dependências do jCompany em /WEB-INF/lib.

Agora no módulo principal adicionaremos a nova dependência:

<dependency> <groupId>empresa.exemplo</groupId> <artifactId>erp-visao</artifactId> <version>1.0</version> <scope>provided</scope> <type>war</type> </dependency>

Relembrando o scope deve ser provided para não ser colocado dentro de /WEB-INF/lib da aplicação.

Mas se o módulo não for colocado dentro de /WEB-INF/lib onde será colocado? Para solucionar esse problema o plugin plc-maven-plugin descompactará o módulo war dentro do projeto gerado! Para isso temos que adicionar a seguinte configuração no pom.xml da aplicação PRINCIPAL: <build> <plugins> <plugin> <groupId>powerlogic.jcompany.maven</groupId> <artifactId>plc-maven-plugin</artifactId> <configuration> <wars> <war>powerlogic.jcompany.jcompany_visao</war> <war>powerlogic.jcompany.jcompany_doc_visao</war> <war>empresa.exemplo.erp-visao</war> </wars> </configuration> </plugin> </plugins> </build>

(11)

Observe que o nome do módulo é adicionado concatenando o groupId com o artifactId. A ordem das tags “war” dizem ao Maven quais arquivos devem ser substituídos caso entrem em conflito de nomes. Assim se quisermos personalizar um arquivo do jCompany Visão não será necessário editar o código no projeto jCompany Visão e depois reconstruir. No exemplo acima se existir um arquivo de mesmo nome no módulo jcompany_visao e no erp-visao, o arquivo do erp-visao sobrescreverá o arquivo do jcompany_visao. Se existir um arquivo com mesmo nome no módulo Principal este terá preferência.

4.3 DEPENDÊNCIAS EXTERNAS

Se o projeto necessitar outras dependências alem dos módulos, basta adicionar a dependência no pom.xml do módulo que necessita do artefato.

4.3.1 EMPRESAS SEM REPOSITÓRIO INTERNO

Se a sua empresa não tem um repositório interno para artefatos Maven e o artefato que queira adicionar não esteja no repositório local o seguinte procedimento é necessário:

Localize o artefato no repositório central

Copie o jar e o arquivo pom para o diretório equivalente no seu repositório interno

4.3.2 JARS QUE NÃO ENCONTRAM-SE NO REPOSITÓRIO PÚBLICO

4.3.2.1 ADICIONANDO UM ARTEFATO AO REPOSITÓRIO LOCAL

Algumas vezes não existe o jar em nenhum repositório público. Para adicioná-lo faça o seguinte: 1. Abra um prompt DOS

2. Digite a linha seguinte, trocando c:\powerlogic para o local de instalação do jCompany

set PATH=c:\powerlogic\maven2\bin;%path%

3. No diretório onde está o artefato que queira adicionar ao repositório digite o comando:

mvn install:install-file –Dfile=”” –DgroupId=”” –DartifactId=”” –Dpackaging=”” -Dversion=”” – DgeneratePom=true

Substitua o groupId, artifactId e version. Packaging é a extensão do arquivo que estão sendo colocado no repositório. File é o nome do arquivo que está sendo copiado para o repositório.

4.3.3 ADICIONANDO UM ARTEFATO AO REPOSITÓRIO DA EMPRESA

Para copiar os artefatos para um repositório remoto da empresa, siga o passos um 1 e 2 do tópico anterior 4.3.2.1 - Adicionando um artefato ao repositório local.

Digite o seguinte comando no prompt DOS:

mvn deploy:deployfile Dfile=”” DgroupId=”” DartifactId=”” Dversion=”” Dpackaging=”” -DrepositoryId=”” -Durl=””

As opções file, groupId, artifactId, version e packaging são iguais para a instalação no repositório local.

(12)

repositoryId é o nome do repositório remoto, configurado no settings.xml. O repositório remoto é configurado pela tag “Server” como mostrado no capítulo 6 - Configurando a máquina do desenvolvedor.

url é o endereço base do repositório remoto. Se o repositório tiver sido instalado de acordo com o capítulo 7.1 - Como Instalar um proxy para a empresa essa url será

HTTP://HOST:PORT/maven/repositorio. Substitua o host e port. Repositório Interno da empresa

O Plc Maven Proxy funciona como um Proxy de artefatos para projetos que utilizam o Maven para construir as aplicações. Esse Proxy facilita o compartilhamento de dependências de artefatos entre projetos reunindo em um só lugar na empresa todos os artefatos de todos os projetos.

4.4 PUBLICADO O PROJETO NO REPOSITÓRIO DA EMPRESA

Caso a empresa tenha um repositório interno, às vezes é necessário publicar o projeto e seus módulos para o repositório remoto. Para isso adicione no arquivo projeto-pom.xml no módulo principal o código: <distributionManagement> <repository> <id> </id> <name></name> <url></url> </repository> </distributionManagement>

Id é o id configurando no arquivo settings.xml consulte o capítulo 6 - Configurando a máquina do desenvolvedor.

Name é o nome do repositório, pode ser qualquer nome.

URL do repositório interno completo. HTTP://host:port/maven/repositorio .

(13)

5 COMANDOS BÁSICOS

Aqui se encontra todos os comandos básicos para execução Maven. Algumas informações contidas nesse capítulo serão melhor compreendidas após leitura completa dessa manual. Para acessar as tarefas básicas configuradas como padrão do jCompany. No Eclipse acesse o menu “Run -> External Tools -> External Tools”. As opções de quais tarefas ser~o executadas s~o definidas no campo “arguments”.

Opções adicionadas por padrão pelo jCompany são:

-o : offline. Evita que o Maven tente achar atualizações em repositórios remotos -npu: “No plugin update”. Evita que o Maven atualize os plugins do próprio Maven.

5.1 INSTALANDO O PROJETO NO REPOSITÓRIO LOCAL

Comando Maven:

mvn –f projeto-pom.xml install

Comando utilizado para instalar o módulo no repositório local. Algumas vezes pode se utilizado para baixar as dependências do repositório interno da empresa quando existir. Possibilitando colocar no path do Eclipse a dependência.

-f projeto-pom.xml indica que será utilizado o arquivo de configuração projeto-pom.xml.

Utilizando esse pom é possível instalar todos os módulos pertencentes ao projeto. Cada módulo configurado no projeto-pom.xml pela tag <module> será executado.

Se não for utilizado o –f projeto-pom.xml apenas o módulo escolhido será instalado.

5.2 INSTALANDO NO REPOSITÓRIO REMOTO DA EMPRESA

Comando Maven:

mvn –f projeto-pom.xml deploy

Deploy para o Maven significa publicar o artefato no repositório remoto. Não confunda deploy do Maven com deploy para servidor de aplicação.

Para utilizar esse comando, a tag Server no arquivo settings.xml deve ser configurada como explicado no capítulo 6 - Configurando a máquina do desenvolvedor e a configuração no pom.xml como explicado no capítulo 4.4 - Publicado o projeto no repositório da empresa.

5.3 FAZENDO DEPLOY NO SERVIDOR DE APLICAÇÃO

Comando Maven:

mvn –f projeto-pom.xml install plc:deploy-completo

Compila todos os módulos, empacota em um war, e pública o artefato no Tomcat definido pela variável $CATALINA_HOME. Essa variável é configurado no start.bat do eclipse.

(14)

5.4 FAZENDO DEPLOY RÁPIDO PARA O SERVIDOR

Comando Maven:

mvn –f projeto-pom.xml plc:deploy-rapido

Copia todos os arquivos (exceto classes) modificados nos módulos, definidos no arquivo projeto-pom.xml, para o Tomcat.

5.5 FAZENDO DEPLOY RÁPIDO COM REINICIALIZAÇÃO

Comando Maven:

mvn –f projeto-pom.xml plc:deploy-reinicializacao

Esse comando faz o mesmo que o deploy rápido, mas copia as classes alteradas também. As classes j| devem ter sido compiladas pelo Eclipse porque o Maven pegar| os arquivos “*.class” do diretório output do Eclipse.

Na primeira vez que se faz o deploy rápido todos os arquivos dos módulos são copiados sem serem colocados dentro do jar correspondente no diretório /WEB-INF/lib. Portanto acontecerá de ter arquivos duplicados dentro do jar e dentro /WEB-INF/classes. Mas isso não causa nenhum efeito colateral porque o Tomcat dará preferência por arquivos que estão em /WEB-INF/classes.

5.6 FAZENDO DEPLOY PARA PRODUÇÃO

Comando Maven:

mvn –f projeto-pom.xml install plc:deploy-completo –P prod

Esse comando gera um war file com as seguintes características: Pré compila as jsps

Muda o par}metro “show_sql” no hibernate.cfg.xml para false Muda as categorias do log4j para Warn.

(15)

6 CONFIGURANDO A MÁQUINA DO DESENVOLVEDOR

As configurações do Maven ficam em jCompany_path/maven/conf/settings.xml.

A localização do repositório local é configurado pela tag <localRepository>. Ao instalar o jCompany o repositório local utilizado fica em jCompany_path/repositorio.

Para acessar o repositório da Empresa caso exista coloque o seguinte: <mirrors> <mirror> <id> </id> <mirrorOf>central</mirrorOf> <name> </name> <url> </url> </mirror> </mirrors>

Esse trecho de configuração diz ao maven que todas as chamadas ao repositório central irão acessar o repositório interno da Empresa.

Em “id” coloque um nome único que represente esse mirror. Em “name” adicione um nome { esse mirror, esse nome aparecerá nos relatórios de build e em “url” coloque a url completa do Maven Proxy. Se colocado essa url em um browser será possível navegar pelo repositório. Portanto ao configurar o mirror confira se a url está certa utilizando um browser.

Para os artefatos que não estão em repositórios públicos, como por exemplo, os artefatos da Powerlogic e os próprios artefatos criados pela empresa são necessários dizer onde encontrá-los também. Adicione a configuração abaixo, apenas troque a Url para a url onde se encontra o repositório da Empresa. <profiles> <profile> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>Principal</id> <name>Repositorio da empresa</name> <url> </url> </repository> </repositories>

(16)

<pluginRepositories> <pluginRepository> <id>Principal_Plugins</id> <name>Repositorio Powerlogic</name> <url> </url> </pluginRepository> </pluginRepositories> </profile> </profiles>

Para que o desenvolvedor possa publicar novos artefatos no repositório da empresa é necessário adicionar a configuração abaixo:

<servers> <server> <id>Principal</id> <username>maven</username> <password>senha</password> </server> </servers>

A configuração acima é a configuração para utilizar o SCP, isto é o usuário e senha para acessar via SCP o repositório da Empresa. Assim na configuração de cada projeto (projeto-pom.xml) basta adicionar o nome(id) do repositório onde será publicado e a sua URL. O usuário e a senha não precisarão ir dentro do projeto.

(17)

7 REPOSITÓRIO INTERNO DA EMPRESA

Todas as dependências do projeto são salvos em um repositório local. Por padrão o jCompany configura a localidade desse repositório para DiretorioBaseDeInstalação/repositorio.

Ao fazer a construção da aplicação utilizando o Maven este automaticamente adiciona ao projeto os artefatos declarados no arquivo pom.xml buscando-os da seguinte forma:

1. Tenta achar o artefato no repositório local.

2. Caso algum artefato não exista no repositório local o Maven tentará achar em um repositório remoto. O repositório remoto pode ser um repositório publico ou um repositório da própria empresa.

3. Caso esteja configurado para utilizar o repositório da empresa, este tentará localizar o artefato, atualizará o repositório local e adicionará ao projeto.

4. Se no repositório da empresa não tiver o artefato este irá procurar nos repositórios públicos. Se mesmo assim não for encontrado o artefato será gerado um erro na construção da aplicação.

7.1 COMO INSTALAR UM PROXY PARA A EMPRESA

O primeiro passo é criar um usu|rio no Windows com o nome “maven”. Para isso v| em “Painel de controle” -> Usuários.

Crie o diretório c:\maven\repositorio.

Copie o diretório Plc-Maven-Proxy para dentro de c:\maven.

7.2 CONFIGURAÇÕES BÁSICAS

Dentro do diretório Plc-Maven-Proxy existe um arquivo chamado “maven-proxy.properties”. Todas as configurações são feitas nesse arquivo.

Chave Descrição

repo.local.store Diretório onde serão colocados os artefatos. Este diretório deve ser relativo ao diretório “serviço”

port Porta em que o Proxy escutará.

snapshot.update Verifica nos repositórios remotos por novas versões de artefatos SNAPSHOTs serverName Nome da máquina que esta localizada incluindo a porta de escuta

A configuração repo.local.store deve ser mantida em c:\maven\repositorio. Mais à frente ao configurar o SCP, se mudado esse local, diversas mudanças complexas terão de ser feitas para configurar o SCP o que não será explicado em detalhes nesse manual.

7.3 CONFIGURAÇÕES DE PROXY

Caso a empresa esteja atrás de um Proxy algumas configurações são necessárias.

Diversos proxys podem ser configurados. Cada configuração deve ter um NOME. Esse nome pode ser qualquer nome que melhor represente a configuração. Apesar de poder ter diversas

(18)

configurações diferentes de Proxy, apenas uma pode ser utilizada. Para selecionar qual configuração utilizar edite a linha

proxy.list=NOME

NOME é a configuração que deseja utilizar

proxy.NOME.host Endereço do servidor de proxy. proxy.NOME.port Porta do Proxy.

proxy.NOME.username Nome de usuário para autenticar no Proxy. Por motivo de segurança esse usuário só precisa ter acesso aos endereços de repositório que serão definidos mais adiante.

proxy.NOME.password Senha para autenticar no proxy.

7.4 CONFIGURAR OS REPOSITÓRIOS PÚBLICOS

Caso os artefatos requisitados não estejam no Proxy Maven este tentará localizar os artefatos em repositórios públicos. Para configurar em quais repositórios procurar adicione as seguintes configurações.

Como podem ter muitos repositórios remotos, adicione a ordem que será verificada com a seguinte configuração:

repo.list=REPO_NOME1,REPO_NOME2

Os repositórios são configurados com opções do tipo repo.REPO_NOME.KEY onde REPO_NOME é o nome do repositório e KEY é o tipo de configuração, que serão detalhadas na tabela abaixo:

repo.REPO_NOME.url Url de acesso ao repositório público repo.REPO_NOME.description Descrição do repositório

repo.REPO_NOME.hardfail

repo.REPO_NOME.cache.period repo.REPO_NOME.cache.failures

repo.REPO_NOME.proxy Qual configuração de proxy utilizar.

7.5 INICIALIZANDO O PROXY

Antes de inicializar o Proxy Maven crie o diretório configurado em repo.local.store.

7.5.1 WINDOWS

Para inicializar o Proxy Maven basta executar o arquivo instalar.bat no diretório “serviço”. Esse bat instalará um serviço no Windows. O serviço inicializará automaticamente toda vez que iniciada a máquina.

(19)

Para executar o Proxy Maven no digite

java –jar maven-proxy-standalone-0.2-app.jar maven-proxy.properties

no prompt de comando.

7.6 VERIFICANDO A INSTALAÇÃO

Após inicializar o Proxy Maven abra um Browser e coloque a url “serverName/maven” onde serverName é a configuração no arquivo maven-proxy.properties. Veja Configurações Básicas. Se algo sair errado verifique o arquivo de log, que se encontra em Plc-Maven-Proxy\log.txt.

7.7 INSTALANDO SERVICO SCP NO WINDOWS

A configuração que fizemos acima resolve um problema, baixar os arquivos de repositórios remotos. Mas para a solução ficar completa é necessário instalar outro serviço que permitirá o oposto, enviar arquivos da máquina do desenvolvedor para um repositório remoto.

Para poder enviar um arquivo a um repositório remoto é necessário que esse repositório possa ser acessado via SCP.

A instalação do serviço SCP não é muito trivial, portanto siga exatamente os passos a seguir. 1. Execute o arquivo “setupssh.exe” e siga a instalaç~o deixando tudo como padr~o. 2. Abra um prompt DOS.

3. Entre no diretório onde foi instalado o OpenSSh. Ex: cd “C:\Program Files\OpenSSH\bin”

4. Execute o comando: “mkgroup -l >> ..\etc\group”

5. Execute o comando 2 VEZES : “mkpasswd -l -u maven >> ..\etc\passwd” 6. Abra o registro do Windows com o comando: “regedit”

7. Na pasta “HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/home” edite a chave “native” para “c:\”

8. Em “HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\” adicione um DWORD Value com nome “Cygdrive flags” e valor 2a em Hexa

9. Adicione na pasta “HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus

Solutions\Cygwin\mounts v2\” um String de nome “Cygdrive prefix” com valor “/” Inicialize o serviço do Windows de nome “OpenSSH”