maven – Página: 2 – Blog do Camilo

Jersey com JSON em 5min

Olá Pessoal,

O post de hoje tem como objetivo ensinar como retornar um objeto JSON usando Jersey em 5min. Então acredito que você já sabe o que é Jersey e o que é um objeto JSON, certo? Vou pular toda a teoria e ir direto para prática.

Lets go…

Starting

Crie um projeto maven webapps
No pom.xml deixe assim :

<dependency>

       <groupId>com.sun.jersey</groupId>

       <artifactId>jersey-server</artifactId>

       <version>1.8</version>

    </dependency>

    <dependency>

       <groupId>com.sun.jersey</groupId>

       <artifactId>jersey-json</artifactId>

       <version>1.8</version>

    </dependency>

<build>

    <finalName>hellojersey</finalName>

</build>

Em src/main/java crie um package e uma classe:

HelloJerseyService.java

É a classe que terá o serviço, veja:

@Path(“/hello”)

public class HelloJerseyService {

       @GET

       @Path(“/client”)

       @Produces(MediaType.APPLICATION_JSON)

       public Client getCliente() {

             Client client = new Client();

             client.setName(“Hello World Camilo”);

             return client;

       }

}

@Path – aqui estamos dizendo que caminho seguir para acessar esse serviço. E para obter um cliente é através do /client sendo a url completa assim /hello/client

Crie a classe Client.java

public class Client {

       private String name;

       public String getName() {

             return name;

       }

       public void setName(String name) {

             this.name = name;

       }

}

Abra o arquivo web.xml, pois precisamos dizer que vamos usar o Jersey e fazer umas configurações, portanto crie o servlet a seguir:

<servlet>

<servlet-name>jersey-servlet</servlet-name>

<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>

<init-param>

   <param-name>com.sun.jersey.config.property.packages</param-name>

   <param-value>com.camilolopes.jersey.services</param-value>

</init-param>

<init-param>

   <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>

   <param-value>true</param-value>

</init-param>

</servlet>

No primeiro init-param estamos dizendo onde está o package com a classe de serviço para o Jersey. No segundo estamos dizendo: “pode ser retornado um objeto JSON”. E aqui:

<servlet-mapping>

<servlet-name>jersey-servlet</servlet-name>

<url-pattern>/rest/*</url-pattern>

</servlet-mapping>

Estamos configurando o mapping para acessar essa parte da aplicação, ou seja, será:

http://localhost:8080/hellojersey/rest/hello/client

Testando:

Execute o seguinte comando:

maven mvn tomcat:run

E acesse pelo browser http://localhost:8080/hellojersey/rest/hello/client

Simples não? Vou ficando por aqui.

See ya!!

Abraços.

Gerando Artifacts Maven para Github

Olá Pessoal,

No post de hoje vamos ver como gerar um artifacts usando Maven e o Github, ou seja, vamos dizer que você precisa fazer um deploy e quer deixar isso automático e que o .jar, por exemplo, já fique na pasta específica.

Lets go…

Certamente você não vai querer fazer deploy manualmente, certo? E gostaria que esse fosse integrado com o seu build e seu repositório. Na semana passada eu passei por uma situação assim e fui pesquisar para ver como fazer. Veja o contexto a seguir.

Contexto

Estava concluída a primeira versão da API para JSF: a I4JSF, mas não sabia como fazer um deploy direto para o GitHub, ou seja, ao chamar o comando mvn deploy gostaria que o artifact já fosse publicado no Github. É muito simples. Vejamos os passos a seguir:

Passo 1 – Altere o arquivo setting.xml do maven, normalmente localizado em .m2/config. Adicione nas tags <Servers/>

<server>

      <id>github</id>

      <username>SEU_USERNAME</username>

      <password>SUA_SENHA</password>

    </server>

Passo 2 – Altere o pom.xml do seu projeto

<!– tell the github site-maven–plugin about the new server –>

<properties>

<!– github server corresponds to entry in ~/.m2/settings.xml –>

<github.global.server>github</github.global.server>

</properties>

<!– Finally, tell the site plugin where the artifact has been deployed –>

<distributionManagement>

<repository>

<id>github</id>

<name>GitHub ${project.artifactId} Repository</name>

<url>https://raw.github.com/camilolopes/${project.artifactId}/mvn-repo</url>

</repository>

</distributionManagement>

Adicione o plugin site-maven-plugin ao pom.xml

<!– Plugin for GITHUB –>

<plugin>

<groupId>com.github.github</groupId>

<artifactId>site-maven–plugin</artifactId>

<version>0.8</version>

<configuration>

<message>Maven artifacts for ${project.version}</message>

<noJekyll>true</noJekyll>

<outputDirectory>${project.build.directory}/mvn-repo</outputDirectory>

<branch>refs/heads/mvn-repo</branch>

<includes>

<include>**/*</include>

</includes>

<repositoryName>your_repository_name</repositoryName>

<repositoryOwner>YOURUSERNAME</repositoryOwner>

</configuration>

<executions>

<execution>

<goals>

<goal>site</goal>

</goals>

<phase>deploy</phase>

</execution>

</executions>

</plugin>

Passo 3 – Adicione o plugin de deploy

<!– setting deploy in github artifacts –>

<plugin>

<artifactId>maven-deploy-plugin</artifactId>

<version>2.7</version>

<configuration>

<altDeploymentRepository>internal.repo::default::file://${project.build.directory}/mvn-repo</altDeploymentRepository>

</configuration>

</plugin>

Não se preocupe com a branch mvn-repo, ela será criada automaticamente.

Passo 4 – Execute mvn clean deploy e aguarde o download dos plugins.

Acesse o GitHub e veja que a branch mvn-repo foi criada. É onde ficam os .jars:

Pronto, agora ao executar mvn deploy o .jar já vai automaticamente para o GitHub. Fantástico, não?

Adicionando dependência em outro projeto

Vamos dizer agora que um projeto X decidiu usar seu .jar via maven. O que fazer? Veja a seguir o que ele precisa adicionar no pom.xml:

<!– I4JSF –>

                <repository>

        <id>I4JSF-mvn–repo</id>

        <url>https://raw.github.com/camilolopes/I4JSF-API/mvn-repo/</url>

        <snapshots>

            <enabled>true</enabled>

            <updatePolicy>always</updatePolicy>

        </snapshots>

    </repository>

E nas dependências:

<dependency>

     <groupId>com.i4jsf</groupId>

     <artifactId>i4jsf</artifactId>

     <version>1.0.0</version>

     </dependency>

Vou ficando por aqui.

See ya!!!

Série CI: Executando unit tests Jenkins via Maven

Olá Pessoal,

No post de hoje veremos como executar os unit tests, após executarmos mvn compile. Vou considerar que você já tem o Jenkins instalado e um projeto configurado.

Lets go…

Starting…

Primeiro passo é ir em configure do projeto no Jenkins, pare o mouse em cima do projeto/job criado e escolha configure.

Em Build, configuramos para rodar mvn compile.

Mas e se você quiser também rodar os unit tests? Simples, basta adicionar mvn test

Clique no botão add build step escolha Invoke top-level Maven targets e deixe conforme a imagem a seguir:

Pronto, após o compile vamos executar os testes.

Um problema

Se você mandar construir uma build e todos os testes tiverem passando, você não tem problemas aparentemente, mas faça um teste falhar e mande construir. Certamente verá isso:

Ué, um teste falhou, mas o build foi dado como sucess. Esse é o problema e vamos resolver.

Solução

A solução é muito simples, apenas vamos dizer que as falhas na execução de qualquer unit tests não podem ser ignoradas, para isso precisamos atualizar o comando mvn test, deixando assim:

test -Dmaven.test.failure.ignore=false

Salve as alterações e rode uma nova build clicando em build now. E aguarde….

Resultado

É isso que esperamos:

Pronto. Agora sempre que um teste falhar a construção da build também vai falhar.

Vou ficando por aqui e espero que tenham gostado do post.

See ya!!

Série CI:Maven + Jenkins + Git

Olá Pessoal, no post de hoje vamos ver como integrar maven + jenkis + git. É algo aparentemente simples, mas que na primeira vez me deu umas dores de cabeças chatas até deixar tudo redondo e resolvi compartilhar com vocês.

Lets go…

O problema

Sempre temos que ter um problema para que o nosso dia fique mais emocionante. Então eu tinha alguns:

Queria montar um ambiente automatizado com o jenkins ;
Queria conectar o jenkins com o git;
Queria fazer meu jenkins buildar pelo maven ;
Não ter um Java Project apenas;
Não queria ter mais de um repositório no Git, ou seja, nada de um repositório por projeto.

Bem, do problema 1 ao 3 eu já tinha resolvido facilmente, mas os pontos 4 e 5 estavam me incomodando, porque eu queria ter mais de um projeto para ter as coisas organizadas e melhor para trabalhar, sem falar que a manutenção fica mais fácil. Também há outro fator, eu sou preguiçoso para coisas repetitivas, odeio ter que fazer mais de uma vez o mesmo trabalho. Gosto de fazer o trabalho chato uma vez e se precisar mudar algo amanhã, que o esforço seja o mínimo possível.

A solução

Após horas de tentativas de montar a estrutura ideal que queria, cheguei a uma que atendeu ao que precisava, ou seja, atingi os 5 pontos citados anteriormente. Como? Simples assim:

Repositório: crie um repositório git, que aqui chamei de trunk
Parent: crie um maven Project chamado parent. Nele vou colocar as dependências base e comum nos projetos. Adicionei os outros projetos como module do projeto parent.
Filho 1: criei um Project maven chamado readers-core que será um projeto focado apenas no back-end da aplicação.
Filho 2 : criei um Project maven com suporte JSF que será focado na parte de front-end, porém esse projeto tem uma dependência do projeto filho 1 (readers-core).

Cada projeto tem seu próprio pom.xml, isso evita de ter um pom.xml com tudo e sabemos que quando a configuração de XML começa a crescer é um inferno pra ficar dando manutenção e se achar nele. Daí cada projeto terá no seu pom.xml aquilo que ele precisa de fato, por exemplo, o projeto ereaders-core não precisa ter uma dependência JSF definida no pom.xml, porque esse é um projeto que não foca em front-end.

A estrutura ficou assim

–meu repositório git

                –parent-project maven

                               –projeto Java A

                               –projeto Java B

Na prática

Bem, não vou explicar como instalar o jenkins na máquina, nem o Git.No blog há posts relacionados nas devidas sessões.

Crie um repositório Git (O meu chamei de trunk.)
Criando o projeto parent

Esse cara aqui é o mais importante, pois é pra ele que vamos apontar o Jenkins. Portanto, crie um maven Project:

** Você vai precisar ter o Jboss Tools instalado Plugin instalado na sua IDE Eclipse.

No próximo passo

Observe que criei uma pasta chamada parent-project dentro de trunk. Faça isso.

No ultimo passo, deixe conforme a imagem a seguir:

Agora crie dois maven project, porém no segundo passo deixe assim:

** o package você decide. Eu criei um .jar para o projeto core e .war para o projeto web.

No meu caso:

Abra o arquivo pom.xml do parent-project e adicione os dois outros projetos como modules:

Abra o pom.xml de um dos projetos que você criou (no meu caso ereaders-core.) e em parent deixe assim:

Faça o mesmo para o outro projeto.

Para projetos Web

Se você criou um projeto web, terá que alterar seu pom.xml conforme a seguir. No meu caso, criei um maven project e depois adicionei “capacidades de JSF”, isso porque o Jboss tools nos permite fazer isso. Daí a estrutura do projeto fica assim.

Nós precisamos informar ao maven onde está o web.xml para que ele possa gerar o .war.

Para isso, clique com o botão direito no pom.xml do projeto web e vá na opção maven >> add plugin. Na janela que aparece, informe o seguinte:

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-war-plugin</artifactId>

Feito isso, vá no modo de edição do pom.xml e adicione o código abaixo:

<configuration>

<webXml>..\readers-web\WebContent\WEB-INF\web.xml</webXml>

</configuration>

O código completo:

<plugin>

                  <groupId>org.apache.maven.plugins</groupId>

                  <artifactId>maven-war-plugin</artifactId>

                  <configuration>

                  <webXml>..\readers-web\WebContent\WEB-INF\web.xml</webXml>

                  </configuration>

           </plugin>

Se não fizesse, o seu build ia falhar, porque ele não ia saber o caminho do web.xml. Por default o maven ia procurar em seuprojeto\ WEB-INF.

Alterando a versão do Java no maven

Se você estiver usando um projeto web com suporte servlet 3.0 é requerido Java 6, mas o maven por default usa Java 5. Para alterar basta adicionar o plugin no pom.xml do projeto web:

groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

E depois editar adicionando as informações a seguir:

<configuration>

                  <source>1.6</source>

                  <target>1.6</target>

                  </configuration>

Feito isso podemos buildar nosso projeto dentro do eclipse e ver o que acontece, portanto clique com o botão direito no parent-project, vá em Run As >> Maven Install

O resultado final deve ser conforme a imagem acima. Simples, não? Agora foi, mas antes disso tive problemas chatos. Um deles foi esse do .war.

No Jenkins

Agora vamos para o Jenkins e criar um job para buildar esse projeto

O meu chamei de parent-project e escolher a opção maven.

As configurações são bem simples, a mais chata foi a do build, como veremos a seguir. Como estou usando o Git, então informei onde está o repositório:

E no build configurei:

Salve as alterações e clique em Build Now

E o resultado é o build construído.

Bom, essa foi uma das soluções que achei mais viável para o meu projeto. Espero que tenha gostado.

Compartilhe sua experiência… como tem feito?

Abraços, see ya!

Troubleshooting Alterando o context-root no Jboss AS 7

Olá Pessoal,

No troubleshooting de hoje veremos como alterar o nome do context quando estamos rodando uma app com JBoss AS 7. By default o jboss pega o nome do projeto + version do maven e faz o war. Algo assim:

ecommerce-1.0.0.0.0.1-SNAPSHOT.war

Feio chamar aplicação assim no browser né: http://localhost:8080/ecommerce-1.0.0.0.0.1-SNAPSHOT

Solução:

1. Crie um arquivo chamado jboss-web.xml em WEB-INF

2. E adiciona o código assim com o nome do contexto que deseja

<jboss-web>

<context-root>ecommerce</context-root>

</jboss-web>

Pronto, resolvido agora, mas gastei uns minutos para descobrir que era essa a forma.

Abracos, see ya!!