Artigo Java Magazine 61 - WTP 3.0

Para que serve:

Auxiliar o leitor que já usa uma versão anterior do Eclipse, talvez com o WTP 2.0, talvez com outro plugin para Java EE – ou até mesmo outro IDE – a decidir se vale o esforço de migrar para o Ganymede + WTP. E para quem já decidiu, ajudar nos primeiros passos. Além disso, o artigo aproveita para apresentar algumas boas técnicas de estruturação de projetos, para um melhor aproveitamento das vantagens da arquitetura Java EE.

WTP 3.0 em todos os lugares:

O Web Tools Platform chega à sua terceira major version com muitas novidades, mais uma vez correndo atrás do prejuízo. Como sabem os veteranos do Eclipse, o projeto WTP foi uma iniciativa relativamente tardia; durante anos os fãs do Eclipse tiveram que se virar com plug-ins de terceiros, de funcionalidade e qualidade limitadas, e nem sempre livres.

Ainda existem alternativas ao WTP, mas a maioria destas são na verdade extensões do WTP. É o caso, por exemplo, das ferramentas “JBoss Tools” da RedHat, e dos IDEs comerciais da IBM Rational: ambos podem ser resumidos como “O WTP mais alguns plugins extra”. Isso também mostra a maturidade do WTP, que conseguiu ser aceito como componente fundamental de suporte a Java EE em praticamente qualquer IDE baseado no Eclipse, o que reduz problemas como migração de projetos ou de treinamento de desenvolvedores. E isso também torna este artigo relevante para ainda mais leitores: não importa se sua preferência é usar a distribuição “pura” da Eclipse Software Foundation, ou algum IDE derivado (livre ou comercial); seja qual for o caso, é alta a chance que o seu ferramental de suporte a Java EE seja baseado no WTP. Mas para os usuários da distribuição da ESF, a vantagem é que as novas funcionalidades são disponíveis primeiro, enquanto que os IDEs derivados podem levar meses para migrar sua base para o novo JDT, WTP e outros componentes.

O release do Eclipse deste ano, o Ganymede (3.4), foi coberto na Edição 59, mas como o leitor pôde verificar, não foi uma atualização revolucionária do IDE básico. O que é uma boa coisa, pois o JDT é um IDE já tão maduro que não resta muito que melhorar nos fundamentos: editor, depurador, gerenciamento de projetos, etc. Existem, claro, melhorias incrementais que às vezes fazem a diferença para certos projetos ou usuários. Mas nada tão universalmente útil que cause uma grande impressão para a média dos desenvolvedores.

Vimos em outro artigo recente – “EclipseCon 2008”, Edição 58 – que a ESF abre o escopo cada vez mais, ultrapassando as fronteiras de IDEs e incluindo tecnologias de runtime. Porém, mesmo para quem se interessa primariamente pelo IDE, os releases anuais da ESF continuam trazendo novidades importantes; só não mais no JDT, e sim em seus diversos anexos (BIRT, WTP, TPTP) ou alternativas para outras linguagens (DLTK, CDT). De todos estes, sem dúvida o mais importante é o WTP – Web Tools Platform – que complementa o JDT com todo o suporte à plataforma Java EE: aplicações web (JSP, JSF etc.), EJB, web services, XML e outras tecnologias.

Na Edição 51, em “Web Tools Platform 2.0”, examinamos a versão anterior do WTP, que fez parte do Eclipse Europa. Nas conclusões, escrevi: “O Eclipse, mesmo com as primeiras versões do WTP, já foi o patinho feio dos IDEs para J2EE/Java EE; mas isso mudou. Com o Eclipse 3.3 e o WTP 2.0, temos finalmente um suporte abrangente e poderoso para as necessidades mais importantes em aplicações “enterprise” ou “server side”.” Afinal, o WTP 2.0 era a primeira versão que trazia recursos (hoje) fundamentais, como edição visual de JSP/JSF e um suporte razoável à JPA e EJB 3.0. Mas ao mesmo tempo, apontei várias lacunas que continuariam classificando o WTP em segundo lugar, frente a outros IDEs com suporte a Java EE mais antigo.

Um ano se passou, e o WTP deu um novo salto. Uma das maneiras de medir esse salto é pelo tamanho do download: o arquivo WTP Runtime 2.0 possuía 37Mb, enquanto o download equivalente do WTP 3.0 possui 59Mb: 60% maior, algo compatível com a mudança de versão 2.0 para 3.0. Vamos examinar as novidades desta versão, e julgar mais uma vez se – finalmente – a ESF atingiu o objetivo de tornar o Eclipse um IDE Java EE 5 peso-pesado, sem dever nada a ninguém.

Instalação

Para acompanhar este artigo, recomendamos ao leitor a instalação da distribuição Eclipse IDE for Java EE Developers. Esta distribuição embute tudo que precisaremos – o Eclipse 3.4, Data Tools Platform 1.6.0 e WTP 3.0, entre outras dependências.

Por database, vamos utilizar o JavaDB que é instalado junto com o Sun JDK 6. Como servidor de aplicação, o Glassfish V2 UR2. Mas você pode usar outro servidor Java EE 5 que seja suportado pelo WTP (ver seção seguinte), bem como outro SGBD de sua preferência, pois não utilizaremos nenhum recurso avançado ou exclusivo do Glassfish ou do JavaDB. Para o leitor que ainda não tem familiaridade com o Glassfish, veja o quadro “Glasfish? Por que não o Tomcat ou JBoss?”.

Glassfish? Por que não Tomcat ou JBoss?

O leitor fiel desta coluna deve ter notado minha “queda” pelo Glassfish, já há um certo tempo (pelo menos desde o V2). E como ficam os leitores fãs do Apache Tomcat ou do JBoss, tradicionalmente os servidores J2EE / Java EE open source mais populares?

Eu prefiro não fazer comparações entre estes servidores, até por não ter experiência igualmente aprofundada com todos eles. Mas algo que faço questão, pelo menos quando tenho a liberdade de escolha, é utilizar produtos que (a) são bem suportados, (b) acompanham de perto as últimas tecnologias, e (c) se possível, que sejam software livre.

O projeto Apache Tomcat não me parece ir bem. O Tomcat 6 (versão atual) só teve dois builds estáveis: o release inicial de 2007 e um único update. Houve defecção de colaboradores importantes – como pessoal da Sun, realocado para o Glassfish quando este começou a levantar vôo, e para outros projetos como o LWUIT. Tecnologicamente o Tomcat parou no tempo há um par de anos. Fez a opção de reusar o APR (biblioteca de código nativo do Apache HTTPD), ao invés de investir forte no caminho “puro Java” de APIs como java.nio – opção que o Glassfish provou ser superior. Não tem havido atualizações de correção & segurança com a regularidade que considero necessária para software dessa natureza. Continuo considerando o Tomcat uma boa opção apenas para ambientes onde toda a comunicação HTTP tem que passar pelo Apache HTTPD.

Já o JBoss ainda se arrasta na produção do JBoss 5.0, cujo desenvolvimento passa de três anos, ainda sem data para o GA. O time da RedHat/JBoss volta e meia vem lembrar que o JBoss 4.2 suporta as “partes principais” do Java EE 5, argumentando que “80% dos clientes não estão esperando por um servidor Java EE 5 certificado” (www.jboss.org/feeds/post/jboss_as_5_0_status). Isso não passa de desculpa – se o JBoss 5 tivesse sido finalizado há dois anos, o discurso seria diferente. O fato é que houve algum problema, talvez a fusão RedHat/JBoss, talvez a reestruturação do microkernel do JBoss 5 que se mostrou mais trabalhosa que o esperado. Espero que o projeto JBoss volte aos trilhos, pois é um ótimo produto, com o atrativo de subprojetos inovadores como o Seam. Mas prefiro esperar até que a crise passe. Quanto ao suporte parcial do JBoss 4.2 para Java EE 5, comecei a avaliá-lo, mas ao descobrir que o container nem é capaz de fazer deploy de um EAR sem o ...