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

Transcrição

1 1 CONTEÚDO 1 Conteúdo Introdução Fundamentos Básicos do Maven Estrutura de diretórios e ciclo de execução Repositórios Introdução às configurações do maven Dependências Depedências de módulos Visão Dependências externas Empresas sem repositório interno Jars que não encontram-se no repositório público Adicionando um artefato ao repositório da empresa Publicado o projeto no repositório da empresa Comandos básicos Instalando o projeto no repositório local Instalando no repositório remoto da empresa Fazendo deploy no servidor de aplicação Fazendo deploy Rápido para o servidor Fazendo deploy rápido com reinicialização Fazendo deploy para produção Configurando a máquina do desenvolvedor Repositório Interno da empresa Como Instalar um proxy para a empresa Configurações Básicas Configurações de proxy Configurar os repositórios Públicos Inicializando o proxy Windows Linux Verificando a instalação Instalando servico SCP no Windows... 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 $CATALINA_HOME/c onf/catalina/localhos t/nome_projeto.xm l NOME_PROJETO.xml - DESENVOLVIMENTO Os arquivos de contextos serão copiados no plc:deploy-reinicializacao e no plc:deploycompleto /src/main/java Arquivos Java que devem ser compilados. /WEB-INF/classes /src/main/resources Arquivos devem ser colocados no path da /WEB-INF/classes aplicação /src/main/webapps Arquivos gerais como.jsp,.css o diretório /WEB-INF... /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 Será copiado para a raiz da aplicação 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. Compile Compila os arquivos Java e colocam no diretório temporário.

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 C:\powerlogic\repositorio\com\powerlogic\MeuProjeto\1.0\MeuProjeto-1.0.jar

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: pom.xml powerlogic.jcompany.projeto-plc projetopom.xml empresa.meuprojetoparent pom.xml empresa.modulo1 empresa.modulo2 Para utilizar o jcompany, edite o arquivo projeto-pom.xml no módulo principal da aplicação da seguinte forma: <parent> </parent> <groupid>powerlogic.jcompany</groupid> <artifactid>projeto-plc</artifactid> <version>3.3</version> Configure no projeto-pom.xml o groupid do projeto, artifactid, version e name da aplicação: <groupid></groupid> <artifactid></artifactid> <version></version> <name></name> 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

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: <modules> </modules> <module>../erp-financeiro</module> <module>../erp-rh</module> <module>../erp-principal</module> 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 /erp-rh pom.xml 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 /erp-rh pom.xml pom.xml

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> </parent> <groupid>empresa.exemplo</groupid> <artifactid>projeto-erp</artifactid> <version>1.0</version> <relativepath>projeto-pom.xml</relativepath> 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: <dependencies> <dependency> <groupid></groupid> <artifactid></artifactid> <type></type> <version></version> <scope></scope> </dependency> </dependencies> type é o packaging do artefato que está sendo adicionado. Pode ser jar ou war. Se omitido será considerado como jar. scope diz ao Maven quando ser utilizada essa dependência. Pode ser:

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 erp-principal(pom.xml) precisamos declarar sua dependência com o erpfinaceiro e erp-principal: <dependencies> <dependency> <dependency> <groupid>empresa.exemplo</groupid> <artifactid>erp-financeiro</artifactid> <version>1.0</version> </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> </build> <plugins> </plugins> <plugin> </plugin> <groupid>powerlogic.jcompany.maven</groupid> <artifactid>plc-maven-plugin</artifactid> <configuration> <wars> </wars> </configuration> <war>powerlogic.jcompany.jcompany_visao</war> <war>powerlogic.jcompany.jcompany_doc_visao</war> <war>empresa.exemplo.erp-visao</war>

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 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 JARS QUE NÃO ENCONTRAM-SE NO REPOSITÓRIO PÚBLICO 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 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 Adicionando um artefato ao repositório local. Digite o seguinte comando no prompt DOS: mvn deploy:deploy-file -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 Como Instalar um proxy para a empresa essa url será 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. Execute o commando mvn f projeto-pom.xml deploy no módulo principal da aplicação.

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 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> </mirrors> <mirror> </mirror> <id> </id> <mirrorof>central</mirrorof> <name> </name> <url> </url> 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> </activation> <repositories> <activebydefault>true</activebydefault> <repository> </repository> </repositories> <id>principal</id> <name>repositorio da empresa</name> <url> </url>

16 </profiles> </profile> <pluginrepositories> <pluginrepository> <id>principal_plugins</id> <name>repositorio Powerlogic</name> <url> </url> </pluginrepository> </pluginrepositories> Para que o desenvolvedor possa publicar novos artefatos no repositório da empresa é necessário adicionar a configuração abaixo: <servers> </servers> <server> </server> <id>principal</id> <username>maven</username> <password>senha</password> 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 repo.local.store port snapshot.update servername Descrição Diretório onde serão colocados os artefatos. Este diretório deve ser relativo ao diretório serviço Porta em que o Proxy escutará. Verifica nos repositórios remotos por novas versões de artefatos SNAPSHOTs 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 Chave proxy.nome.host proxy.nome.port proxy.nome.username proxy.nome.password Descrição Endereço do servidor de proxy. Porta do Proxy. 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. 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: Chave repo.repo_nome.url repo.repo_nome.description repo.repo_nome.hardfail repo.repo_nome.cache.period repo.repo_nome.cache.failures repo.repo_nome.proxy Descrição Url de acesso ao repositório público Descrição do repositório 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 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 LINUX

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