Sim, eu fiz um plugin para maven2 (como descrito aqui). E realmente, foi beeeeem mais fácil do que imaginei, mesmo tendo que integrar uma API que nunca tinha ouvido falar na vida para copiar arquivos com o protocolo scp (Jsch).

No fim das contas o plugin ficou muito facil de se usar. Evidentemente ele segue a filosofia do “Convention over Configuration”, então, se você tem um projeto Java EE, com EJBs, assumo que estrutura será mais ou menos assim:

MyProject
    +------ MyProject-core
    +------ MyProject-ear

Para um simples “Hello World” com EJB3, por exemplo. Sendo que seus EJBs estao em MyProject-core, e o seu MyProject-ear é apenas um wrapper para todos os seus artefatos.
Para este exemplo, no pom.xml do MyProject-ear, basta inserir essas linhas dentro de build/plugins:

    <plugin>
<groupId>uol.maven.plugin</groupId>
<artifactId>maven-deployer-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<configuration>
<remote>false</remote>
</configuration>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>delivery</goal>
</goals>
</execution>
</executions>
</plugin>

Com isso, faremos um delivery no jboss local, utilizando a porta 8080 (padrão do plugin). Para alterar este comportamento, podemos fazer, por exemplo:

<configuration>
<serveHost>myServer</serverHost>
<serverPort>8080</serverPort> <!-- 8080 é o padrao -->
<remote>true</remote> <!-- na verdade true é padrao -->
</configuration>

Agora, basta ir na raiz do seu projeto e digitar:

mvn install

e com isso, será feito o delivery do seu ear (não esqueça de que o JBoss tem que estar rodando para funcionar).

Simples né?

Baixe aqui o plugin:Maven Deployer Plugin

Vamos, lá, algo bem corriqueiro: Você tem seu projeto Java EE com a build automatizada via Maven2. Ótimo! Ponto para você. Obviamente você quer fazer o deploy deste teu projeto no teu servidor favorito, então você chama:

mvn deploy

Ok ? Bom, infelizmente este comando apenas copia os artefatos do seu projeto (ear, jar, war) para o repositório remoto, ao invés de colocar um ear, por exemplo, no diretorio de deploy do seu JBoss, Tomcat, Weblogic, etc. Frustrante né ? Bom, mas deve haver alguma maneira de eu fazer isso de forma automatizada. Ficar copiando os jars/ears/wars/ na mão é tão, digamos, chato e antiquadro! Bom, para isso existe o plugin Cargo, que até agora não consegui fazer funcionar satisfatoriamente. Ah, também existe um tal de jboss-maven-plugin (que nem merece um link aqui no meu blog =p).

Já que nenhum desses serviu pra mim, resolvi fazer um plugin. E não é que é bem mais simples do que parece ? Em pouco tempo fiz um plugin que copia o EAR do padrão de aplicação que temos aqui na empresa para o servidor remoto, e chama um JMX para fazer o hot-deploy do mesmo. Bacana né ? Bom, o plugin ainda está em estágio inicial, só funciona no JBoss-4.0.4.GA, e não funciona de forma local (JBoss na sua máquina), mas pe bem promissor, uma vez que uma tarefa bem corriqueira e que ninguem da conta.

Estou preparando uma melhor documentação e logo logo disponibilizo aqui no site um tutorial de como usar o plugin, bem como o plugin em si.

Até breve.

Paralelamente ao meu trampo Java EE, estou desenvolvendo um sisteminha para controle financeiro em Rails. E tudo o que vejo de errado, ou que poderia ser melhor aqui na empresa, estou tentando levar no meu projeto. E uma das coisas é o TDD. Evidentemente testes unitários deveriam ser prioridade em qualquer sistema de informação, mas sabemos que na realidade, as vezes a diretoria pressiona, e você tem que correr com o codigo e deve deixar algo de lado, para encaixar no prazo. Geralmente esse “algo” que fica de lado, é o teste. Com rails/ruby, é possível explorar mais ainda o TDD. Pelo fato de ser uma linguagem dinâmica, é possivel você criar o teste antes do código. Parece estranho né ? Mas isso te força a sempre codificar pensando no teste e sempre testar pensando no código. E acredite, isto faz uma enorme diferença.

Temos alguns sistemas legados aqui na empresa, que não tiveram esta preocupação com o teste. Devido, provavelmente ao que relatei no parágrafo anterior. E agora estamos com muito receio de refatorar o código, pois não temos a segurança que uma boa suite de teste nos daria. Ai você me diz: “Simples! Faça a tal suite de testes, e depois refatora!”. Entretanto, o sistema não foi feito pensando em testes, não foi concebido para ser unitariamente testado. Com isso temos o codigo de negocio completamente vinculado ao acesso ao banco, o que torna praticamente impossível a utilização de uma camada de mocks. Ou seja, estamos em maus lençóis.