Archetype consiste em um jar de projeto desenvolvido com Apache Velocity.  É uma forma bastante interessante para criar projetos maven, baseados em templates/modelos, rapidamente, onde são informados apenas a hierarquia de pacotes, nome do projeto(archetype) e a versão.

Eu utilizo muito os Archetypes quando quero testar algum framework, tentar simular algum erro postado em listas de discussões ou criar exemplos para o blog. Podendo ser utilizado até mesmo em um projeto da sua empresa.

Se você quer padronizar o desenvolvimento de seus projetos, você pode utilizar uma das opções de archetypes disponíveis. Para criar seu projeto ou ver os archetypes disponíveis para executar o comando:

mvn archetype:generate

Após executar esse comando irão aparece os archtypes dos projetos, existentes em Spring, JSF, EJB, SWING, desenvolvimento de plugins, javascript, Spring-MVC, Weld e a integração entre esses projetos. Bastando apenas definir a hierarquia de pacote, a versão e o nome do projeto. Veja:

Crie seus projetos utilizando Archetype Maven Plugin e altere como quiser.

Para resolver esse problema seria executar um teste específico do Selenium dentro do Eclipse como se fosse um teste de unidade do JUnit ou TestNG.

Inicialmente vamos criar uma classe abstrata onde todos os testes do Selenium deverão estender essa classe abstrata. Essa classe terá toda a infra-estrutura para que os testes sejam executados. Exemplos de configurações feitas por essa classe serão iniciar/finalizar a execução do servidor de aplicação onde será feito o deploy da aplicação e configurar o Selenium server para que seja instanciado sua engine.

Para o gerenciamento do servidor de aplicação iremos utilizar as classes do Cargo e o servidor de aplicação utilizado será o Tomcat 6x. Em seguida será necessário adicionar as dependências do Cargo e o Selenium com o escopo de teste para ambos. Essas dependências poderão ser adicionadas no classpath do Eclipse ou ao pom.xml do maven. Nesse exemplo foram adicionados ao pom.xml do maven, conforme abaixo:

<dependency>
   <groupId>org.codehaus.cargo</groupId>
   <artifactId>cargo-core-container-tomcat</artifactId>
   <version>1.0.6</version>
   <scope>test</scope>
</dependency>
   <dependency>
   <groupId>org.seleniumhq.selenium</groupId>
   <artifactId>selenium</artifactId>
   <version>2.0a4</version>
   <scope>test</scope>
</dependency>

Em seguida vamos criar um método para recuperar a instância de um Tomcat existente:

 /**
 * Método responsável para setar todas as configurações iniciais que o tomcat precisa para startar.
 * Aqui que devem ser configurados, caso necessário, variáveis de ambiente, novas propriedades, datasources etc.
 */
 private TomcatExistingLocalConfiguration InitTomcatConfig() {
    String tomcatHome = System.getenv("TOMCAT_HOME");
    if (tomcatHome == null) {
       throw new IllegalArgumentException("The system property TOMCAT_HOME must be defined.");
    }
    TomcatExistingLocalConfiguration localTomcatConfiguration = new TomcatExistingLocalConfiguration(tomcatHome);
    return localTomcatConfiguration;
  }

No método implementado irá buscar o local onde está instalado o Tomcat através da variável de ambiente TOMCAT_HOME e criar uma instância uma desse Tomcat, representada pela classe TomcatExistingLocalConfiguration.

Agora é criar um método para iniciar o Tomcat antes de todas as suites de testes. A minha implementação foi como a seguir:

// Método que será executado antes de todos os testes
 /**
 * Método onde serão implementados todas as configurações iniciais para a realização
 * de todos os testes
 */
 @BeforeSuite
 public void setUp() {
    LocalConfiguration tomcatConfiguration = InitTomcatConfig();

    // Configurações do Container utilizado("tomcat6x") e caminho do WAR
    war = new DefaultDeployableFactory().createDeployable("tomcat6x", "target/exemplo.war",
        DeployableType.WAR);
    tomcatConfiguration.addDeployable(war);

    // Configurações do Tomcat
    container = new Tomcat6xInstalledLocalContainer(tomcatConfiguration);
    container.setHome(tomcatConfiguration.getHome());

    // Start o container
    container.start();

 }

Agora todas as suas classes de teste precisam herdar essa classe e executá-la como um teste de unidade pela sua engine de teste favorita. No meu exemplo foi utilizado a do TestNG.

Dê mais credibilidade ao seu código criando testes e façam a manutenção de sistemas serem menos dolorosas.

Já trabalhei em projetos legados que utilizavam o JUnit como frameworks de testes de unidade, mas sempre sugeria para migrarmos para o TestNG devido as suas vantagens em relação ao JUnit.

Escrevi até um post falando sobre o framework e também criei um projeto simples apresentando alguns de seus annotations.

Existe um plugin para o eclipse para executar os testes do TestNG. Além de todas as features do plugin existe a funcionalidade de converter testes feitos com JUnit3 e JUnit4 por testes do TestNG.

Para isso basta instalar o plugin, clicar com o botão direito do mouse em cima do teste: TestNG > Converter to TestNG. Como você pode ver na imagem abaixo:

Todos os annotations e imports serão convertidos para os do TestNG. Agora é só aproveitar as vantagens e programar.

Bons testes.

Possui uma interface bastante amigável, uma navegabilidade simples e oferece um visão de relatório onde é possível acompanhar a evolução da qualidade código do projeto e compará-los.

Existe um projeto chamado Nemo dedicado a projetos open sources onde é possível ver projetos open source como Jetty, Apache Lucene e Apache Tomcat.

Então, vamos comprar o Sonar para funcionar junto com o maven. A primeira coisa a se fazer é setar as configurações do Sonar no arquivo de configurações do maven settings.xml adicionando:

<profile>
   <id>sonar</id>
   <activation>
      <activeByDefault>true</activeByDefault>
   </activation>
   <properties>
      <sonar.jdbc.url>jdbc:postgresql://localhost/sonar</sonar.jdbc.url>
      <sonar.jdbc.driver>org.postgresql.Driver</sonar.jdbc.driver>
      <sonar.jdbc.username>user</sonar.jdbc.username>
      <sonar.jdbc.password>password</sonar.jdbc.password>
      <!-- SERVER ON A REMOTE HOST -->
      <sonar.host.url>http://localhost:9000</sonar.host.url>
   </properties>
</profile>

O server do Sonar tem que está executando e o endereço deve ser definido no parâmetro sonar.host.url. Nesse exemplo, a URL do servidor do Sonar está definido localmente e com no endereço e portas padrão http://localhost:9000. É necessário também configurar o banco de dados utilizado pelo Sonar, definindo URL, usuário e senha do banco de dados. Para instalar localmente o Sonar Server veja este link.

Depois de configurado, para executar, analisar e salvar os resultados no banco de dados do Sonar apenas execute no maven mvn sonar:sonar. Você pode configurar o Sonar para executar na sua aplicação de integração continua como Hudson que é  perfeitamente compatível, por que tem um Plugin para o Sonar.

Veja o resultado gerado pelo Sonar:

Como ferramenta de integração contínua eu prefiro o Teamcity, mas não existe plugin estável de acordo com a matriz de compatibilidade. Mas para resolver esse problemas, basta adicionar sonar:sonar no comando executado pelo Teamcity.

Sonar é uma ferramenta essencial para seu projeto para ajudá-lo a avaliar suas classes, com relação a complexidade, duplicidade, definição de regras de códigos, cobertura dos testes, gerando relatórios e registrando a evolução do seu código.

“A breakpoint suspends the execution of a program at the location where the breakpoint is set“.

Mas quando você está debugando uma aplicação, às vezes, você não quer parar em cada breakpoint todas as vezes, por exemplo, em um trecho de código que tenha um loop com muitos objetos.

Uma solução para esses casos é o breakpoint condicional. Você pode definir um breakpoint, que a aplicação será suspensa naquele ponto apenas se a condição for verdadeira. Para configurar um breakpoint condicional, clique com o botão direito do mouse no círculo azul e clicar em “breakpoint properties..” no menu. Como na tela abaixo:



Em seguida será apresentado a tela a seguir:



Então você pode configurar uma condição para que o breakpoint pare a execução da aplicação naquele ponto. Na tela acima, foi definido que a aplicação suspensa quando o método de requisição for “POST”.

Existem outras formas de condição para o breakpoint, por exemplo, o número de repetições que o código passou naquele ponto ou definir uma variável, para quando o valor dela mudar a aplicação pare naquele ponto.

Então é isso. Você conhecia essa dica ou conhece alguma dica interessante do eclipse? Comente sobre isso.

<plugin>
   <groupId>org.codehaus.cargo</groupId>
   <artifactId>cargo-maven2-plugin</artifactId>
   <version>1.0.6</version>
   <configuration>
      <wait>false</wait>
      <!-- Container configuration -->
      <container>
         <type>installed</type>
         <containerId>tomcat6x</containerId>
         <home>${TOMCAT_HOME}</home>
      </container>
   </configuration>
   <executions>
      <execution>
         <id>start-container</id>
         <phase>pre-integration-test</phase>
         <goals>
            <goal>start</goal>
         </goals>
      </execution>
      <execution>
         <id>stop-container</id>
         <phase>post-integration-test</phase>
         <goals>
           <goal>stop</goal>
         </goals>
      </execution>
   </executions>
</plugin>
<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <configuration>
   <!-- Skip the normal tests,
                 we'll run them in the integration-test phase -->
      <skip>true</skip>
   </configuration>
   <executions>
      <execution>
         <phase>integration-test</phase>
         <goals>
            <goal>test</goal>
         </goals>
         <configuration>
            <skip>false</skip>
         </configuration>
      </execution>
   </executions>
</plugin>

Em seguida vamos adicionar a dependência do Selenium para implementarmos os testes de aceitação. Basta adicionar ao pom.xml

<dependency>
   <groupId>org.seleniumhq.selenium</groupId>
   <artifactId>selenium</artifactId>
   <version>2.0a4</version>
   <scope>test</scope>
</dependency>

Após adicionar a dependência vamos a classe de teste. Os objetos do browser são acessados através de quatro drivers oficiais: FirefoxDriver, que o driver mais maduro e o utilizado no exemplo, Internet Explorer Driver, testado com as versões IE6, IE7 no windows Vista e XP e aparentemente é o mais lento dos drivers. Tem também o ChromeDriver, relativamente um driver mais novo e o HtmlUnit como o mais leve e rápido dos drivers por que ele emula um browser onde não é necessário instanciá-lo.

Agora vamos interagir com o browser através de métodos da classe FirefoxDriver utilizando métodos como “findElement” passando um WebElement, podendo ser recuperado através da classe By. Como podemos ver no método tentaCadastrarSemNenhumDado:

public void tentaCadastrarSemNenhumDado()  {
    driver.get("http://localhost:8080/CadastroCelular");
	driver.findElement(By.id("botaoSubmit")).click();

	String mensagemErroNome = driver.findElement(By.id("mensagemErroNome")).getText();
	Assert.assertEquals("Campo Nome Obrigatório", mensagemErroNome);

	String mensagemErroDescricao = driver.findElement(By.id("mensagemErroDescricao")).getText();
	Assert.assertEquals("Campo Descrição Obrigatório", mensagemErroDescricao);

	driver.close();
}

O método de teste acima tenta inserir um modelo de celular sem preencher nenhum campo e verifica se as mensagens de campos obrigatórios são exibidas.

Através da classe By é possível recuperar os elementos da aplicação acessando links, pelo nome, tag html, css ou pelo nome do link. Nessa versão do Selenium existe também a annotation @FindBy que foi uma forma de deixar o código mais limpo e de fácil manutenção. Com essa annotation é uma alternativa para localizar um WebElement. No caso, o método anterior foi desenvolvido sem a utilização da annotation, agora veja o mesmo método desenvolvido com a annotation @FindBy:

     @FindBy(id = "botaoSubmit")
	private WebElement botaoSubmit;

	@FindBy(id = "mensagemErroNome")
	private WebElement msgErroNome;

	@FindBy(id = "mensagemErroDescricao")
	private WebElement msgErroDescricao;

	@Test
	public void tentaCadastrarSemNenhumDado() {
	    driver.get("http://localhost:8080/CadastroCelular");
		botaoSubmit.click();

		Assert.assertEquals("Campo Nome Obrigatório", msgErroNome.getText());

		Assert.assertEquals("Campo Descrição Obrigatório", msgErroDescricao.getText());

		driver.close();
	}

Perceba que no exemplo final o código final ficou bem mais simples e limpo. A configuração e a implementação dos testes funcionais são tão simples que não existem desculpas para não testar suas aplicações. Bons testes a todos.

3
4
5
6
7
8
9
10
11
12
13

<web-app>
<servlet>
      <servlet-name>spring-mvc</servlet-name>
      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
      <servlet-name>spring-mvc</servlet-name>
      <url-pattern>/</url-pattern>
</servlet-mapping>
</web-app>

Na inicialização o servlet ‘spring-mvc’ DispatcherServlet irá procurar pelo arquivo spring-mvc-servlet.xml ( [Nome do Servlet]-servlet.xml ) dentro da pasta WEB-INF do seu projeto. No exemplo acima, todas as requisições serão tratadas também pelo servlet ‘spring-mvc’ DispatcherServlet.

Sobre os Controllers, o Spring possui tipos específicos de controllers de formulário(form-specific controllers), command-based controllers e etc. Para definir que uma classe como Controller basta anotá-la como @Controller como temos no exemplo da classe CelularController

3
4

@Controller
public class CelularController {

As classes anotadas como @Controller irão interpretar e transformar em dados vindos de um formulário em dados do modelo.

Na CelularController existe outra anotação chamada @RequestMapping, onde você mapeia qual o endereço da URL que precisará acessar para que o método seja chamado, através do parâmetro “value”. O parâmetro “method” existe para definir como vai ser o método de request(GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE). Na classe CelularController temos como exemplo:

3
4
5
6

@RequestMapping(value = "/cadastro/remove", method = RequestMethod.POST)
public String removerModelo(@RequestParam(value = "nome", required = true) String nome,
    @ModelAttribute Celular celular, WebRequest request) throws Exception {
}

Existe também a anotação @ModelAttribute. Definindo um atributo com essa anotação o Spring irá fazer o bind dos parâmetros vindo do request para os atributos desse objeto.

A grande mágica acontece quando você cria um método é anota como @InitBinder, assim no exemplo:

3
4
5
6
7
8

    @InitBinder
    public void initBinder(WebDataBinder binder) {
        binder.registerCustomEditor(String.class, new StringTrimmerEditor(false));
        binder.setValidator((org.springframework.validation.Validator) this.validator);
 
    }

@InitBinder permite identificar métodos que inicializarão o WebDataBinder que é utilizado para popular os atributos vindos do formulário com os atributos dos objetos anotados com @ModelAttribute.
Para que essas classes mapeadas com @Controller, @ModelAttribute ou @InitBinder sejam Injetadas pelo container do Spring é preciso que no arquivo spring-mvc-servlet.xml seja mapeado o pacote onde essas classes estarão. No caso do exemplo:

3

<context:component-scan base-package="net.valdemarjr" scoped-proxy="targetClass" />

Para fazer a configuração do Struts Tiles com Spring MVC será necessário definir dois beans no spring-mvc-servlet.xml:

3
4
5

<bean id="tilesViewResolver" class="org.springframework.web.servlet.view.UrlBasedViewResolver"
p:viewClass="org.springframework.web.servlet.view.tiles2.TilesView" />
<bean id="tilesConfigurer" class="org.springframework.web.servlet.view.tiles2.TilesConfigurer" />

E então fazer os métodos das classes de controle retornar a String mapeada no arquivo tiles.xml. Por exemplo no método “processarFormulario”, o retorno no método é “cadastro.formulario”, que está definido como:

3
4
5

<definition name="cadastro.formulario" extends="titulo">
<put-attribute name="conteudo" value="/WEB-INF/jsp/cadastro/formulario.jsp" />
</definition>

Fazendo com que a página seja retornada para o JSP “formulario.jsp”.



Nunca tinha utilizado o Spring MVC, achei legal utilizar todo o poder do Spring para um framework MVC e integrado com Struts Tiles que potencializa a capacidade de componentização da camada de apresentação. Bom é isso, o projeto está no github e pode ser baixando, testado e alterado.

A maldição diz: “aquele programador que não fazer aparecer magicamente uma tela preta escrita Hello World, não vai aprender a linguagem que está estudando .” O algorítimo da maldição seria algo parecido com:

3
4
5
6

Se (programadorstart != ‘Hello World’)
 {
   Linguagemaprender = false;
}

Lógico que isso é uma brincadeira entre os programadores e que você não vai deixar de aprender uma linguagem por não ter desenvolvido um “Hello World” ou um “Alô mundo”, mas nunca se sabe…

Então como iniciei meus estudos em Android e meu primeiro exemplo foi um Hello World, lógico, então para evitar essa maldição resolvi postar meu exemplo no github.

Aproveitando para mostrar o livro que estou lendo Android para desenvolvedores. A versão do android do livro é um pouco antiga 1.5, mas é uma boa referência para ter uma base como principais componentes, exemplos e ciclos de vida dos objetos.

Fica a dica e o meu exemplo.

Estou subentendendo que o java e maven estão devidamente configurados. Caso tenham dúvida como configurar o maven, procure a sessão Installation Instructions aqui. Só um detalhe, a versão do flashplayer tem que ser a versão com debug que pode ser baixada aqui.

Então, vamos criar um projeto de aplicação em flex utilizando Flexmojos4. Irei utilizar a versão 4.0-alpha-5.

Execute o comando abaixo para criar um projeto do tipo Application:

4
5
6

mvn archetype:generate -DarchetypeRepository=http://repository.sonatype.com/content/groups/flexgroup 
-DarchetypeGroupId=org.sonatype.flexmojos -DarchetypeArtifactId=flexmojos-archetypes-application 
-DarchetypeVersion=4.0-alpha-5

O maven irá baixar as dependências necessárias e informar qual será o groupId (geralmente a mesma hierarquia de pacotes), artifactId (nome do seu projeto), versão e o package (hierarquia de pacotes). O exemplo feito está como na imagem abaixo:

“Y” para confirmar, então o projeto será criado.

Iremos utilizar a versão 4.0-beta-2 do flexunit. Edite o arquivo pom.xml e mude a versão da dependência do flexunit de 0.85 para 4.0-beta-2, ficando como abaixo:

1
2
3
4
5
6
7

<dependency>
<groupId>com.adobe.flexunit</groupId>
<artifactId>flexunit</artifactId>
<version>4.0-beta-2</version>
<type>swc</type>
<scope>test</scope>
</dependency>

Será necessário mudar o teste gerado pelo flexmojos, pois ele não utilizar os metadatas do Flexunit4. Basta remover o trecho “extends TestCase” e adicionar o metadata “[Test]” (sem aspas) em cima do método testNothing().

Agora execute o comando “mvn clean install” para que rode o teste que foi criado automaticamente pelo flexmojos. O maven novamente irá baixar todas as dependências necessárias (que não são poucas).

Após executar o comando, deve acontecer o seguinte erro: Cannot run program “FlashPlayer.exe”. Isso acontece por que você deve dizer para o flexmojos o caminho do flashplayer que será utilizado nos testes. No meu caso está no caminho C:\java\Flex Builder 3 Plug-in\Player\10\win\FlashPlayer.exe. Isso é resolvido adicionando a propriedade flex.flashPlayer.command ao pom.xml:

3
4
5

<properties>
<flex.flashPlayer.command>C:\java\Flex Builder 3 Plug-in\Player\10\win\FlashPlayer.exe</flex.flashPlayer.command>
</properties>

Execute novamente o comando “mvn clean install”, então flashplayer será executado e o teste de unidade do flex será realizado com sucesso!

O código do exemplo pode ser baixado no github.

A primeira que tem que ser verificada é tentar instalar o eclipse, o Helios e depois o plugin do Flex Builder 3 do eclipse caso não funcione, temos algumas alternativas:

• Após o Flex Builder 3 plugin ser instalado, é criado um novo diretório dentro do diretório do eclipse chamado “links”. Dentro tem um arquivo chamado “com.adobe.flexbuilder.feature.core.link”. Edite esse arquivo. Irá perceber que tem o caminho onde foi instalado o Flex Builder 3 plugin. Caso não tenha o atributo “path=” antes do caminho do plugin, adicione e reinicie o eclipse.
  
  

Fiz um teste e fazendo a primeira parte resolve o problema. Mas caso não funcione, quando reiniciar o eclipse deverá lançar uma exception. Para resolver esse problema é preciso:

• Baixar o ProblemManager patch. Ir no diretório “Flex Builder 3 Plug-in\eclipse\plugins\com.adobe.flexbuilder.project_3.0.214193\“. Descompactar, com Winrar ou similar, dentro do arquivo “zornproject.jar“, no caminho “com/adobe/flexbuilder/project/compiler/internal“.

Reinicie o eclipse e basta ir em “Window > Open Perspective > Other” e Voilá! Depois de alguns testes, não consegui identificar nenhum problema. O plugin parece funcionar normalmente.

Valdemar Jr ( Tentando resolver os problemas, para uma codificação melhor )