Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the “old” format.

Basicamente é definido um formato de dados através de ficheiros denominados proto files e depois a partir destes é gerado código que sabe ler e escrever num formato binário que é muito pequeno e muito rapido de fazer parse. Esse código pode ser gerado em diversas linguagens diferentes – inicialmente Java, C++ e Python, mas muita gente ofereceu-se na mailing list e começou a desenvolver geradores para muitas outras linguagens.

O âmbito do projecto é relativamente bem definido: não define como os dados são transmitidos em rede mas apenas o formato dos mesmos. Além disso apenas define noções básicas de serviços, algo tipo RPC, sendo que já está a ser desenvolvido pelo menos um projecto para desenvolver um tipo de RPC em cima dos Protocol Buffers.

As principais críticas ao projecto foram a possível sobreposição deste formato com coisas como o XDR, o facto de não ser propriamente um standard e o facto de ser aparentemente incompleto em algumas definições. Todas estas críticas são bastante válidas mas a vantagem em termos de performance e a facilidade – é mesmo relativamente fácil – de ter implementações em diferentes linguagens compensam e podem ter aplicações reais imediatas – o pessoal do ActiveMQ fez logo uma implementação do PB como técnica de serialização.
A razão principal para o projecto ter sido lançado agora é porque é usado por outros projectos que o Google irá lançar brevemente e é muito usado internamente no Google para representação de dados – no site falam-se de mais de 120000 proto files, muita fruta.

Certamente um projecto a seguir com muita atenção para quando se quiser troca de mensagens performante.

Todos os dias a primeira sessão do dia no JavaOne é uma General Session e começa às 8h30 da manhã. Tendo em conta que normalmente são vendor talks (Oracle, AMD, etc.) ficou oficialmente decidido que essa hora será sempre gasta na noite anterior no consumo de cerveja.

The Script Bowl: A Rapid-Fire Comparison of Scripting Languages

O dia começou com um painel muito muito interessante sobre linguagens de scripting ou, como prefiro chamá-las genericamente, dinâmicas. O painel consistiu de 4 linguagens (Groovy, JRuby, Jython e Scala) cada uma com um seu defensor a quem cabia o papel de defender a sua linguagem preferida em 3 rounds. Os defensores eram os seguintes:

• Guillaume Laforge pelo Groovy
• Charles Nutter pelo JRuby
• Frank Wierzbicki pelo Jython
• Jorge Ortiz pelo Scala

A sessão consistiu em 3 rounds, em que o público podia votar por sms em tempo real. Os rounds eram os seguintes:

1. Criar uma aplicação cliente de twitter (applet)

Aqui tanto a aplicação em groovy como em jruby destacaram-se pelo aspecto gráfico polido. A solução em jython foi bastante básica e em cima do joelho e a de Scala mostrou muito bem como usar closures para tratar de eventos e deixou uma impressão muito boa.

2. Criar uma aplicação web que gerisse países e cidades, com integração com mapa

Aqui o groovy dominou totalmente com o Grails. Além de o código ser muito mais perceptível do que o de jruby com o rails, usou uma tag custom para a integração do mapa que deixou a audiência com os olhos a brilhar. A solução do jython foi com django e limitou-se a demonstrar a geração automática da secção de admin sem grandes costumizações, nem mesmo com o mapa. O moço do Scala deitou tudo a perder não tendo implementado a aplicação web porque perdeu muito tempo na applet – e ele é um dos core developers do Lift, uma web framework escrita em Scala!. Aproveitou para demonstrar as funcionalidades de comet / reverse ajax / data push de uma forma simples.

3. O último round foi um vale tudo – basicamente pediram para mostrarem e defenderem o que a linguagem deles

fazia melhor que as outras.
O defensor do Groovy optou por defender a integração com Java; o Charles Nutter mostrou uma aplicação muito interessante em que uma aplicação de visualização respondia ao som e pitch da voz dele; o do jython não me lembro realmente do que disse; o do Scala defendeu a forma como o Scala trata da questão de concorrência com os actors.

Foi uma sessão com um ambiente descontraído, com demonstrações giras. A idea com que fiquei foi muito favorável para o Groovy/Grails e para o Scala, para coisas mais server-side.
Na votaçao do público, o JRuby recebeu os votos dos seus fãs e ficou em primeiro, seguido do Groovy, Scala e Jython em último.

Improving Application Performance with Monitoring and Profiling Tools

De seguida fui para uma apresentação que foca no meu outro tema de preferência além da área web: performance/concorrênca. Falou-se de ferramentas de CPU, de memória e de uso genérico.
Esta apresentação consistiu numa apresentação de uma enormidade de aplicações que se podem usar para monitorizar e fazer profiling de aplicações java. Foram elas:

• DTrace

O DTrace é interessantíssimo e já tinha lido alguma coisas sobre o mesmo, especialmente do pessoal dos Macs. E aí reside a sua principal limitação: apenas está disponível em Solaris e OS X no JDK 6 e eu não conheço nenhum sistema de produção que tenha esta configuração.
Permite obter informações muito importantes como seja a contenção de locks, o tempo de garbage collecting ou os tempos de invocaçao por método. Tudo isto é obtido de forma live, em que se faz attach ao processo java que está a correr e se retiram os dados enquanto ele executa.
No entanto, DTrace é relativamente complexo pois implica a criação de scripts próprios (chamados DScripts). Foram indicadas duas ferramentas auxiliares: Chime para formatar o output e D-Light, que é um UI para criar DScripts facilmente.

• Sun Studio Collector/Analyser

Ao contrário do DTrace, o Collector não faz attach a um processo e funciona por sampling. Ou seja, temos de correr um processo num outro ambiente, que vai recolher dados para analisar e depois para o processor e usar o Sun Studio. Está disponível tanto em Solaris como em Linux.
Serve como substituto do DTrace para quando não se usa Solaris ou OS X.

• JPS, JInfo e JStack

Estas aplicações são bastante simples e disponível nas versões 1.4.2+. O JPS permite listar process IDs de aplicaçoes java a correr; o JInfo permite ver informações como propriedades de sistema, flags da VM e inclusivamente mudar as flags da VM (Permite-nos retirar estas informações a partir de um core dump); JStack permite-nos gerar stack traces de forma simples e é bastante útil para identificar deadlocks.

• BTrace

O BTrace não é bem uma aplicação mas mais uma framework. Permite-nos criar os nossos proprios scripts, que tiram partido de anotações, para obtermos as informações desejadas através de bytecode intrumentalization. Está disponível apenas na versão JDK 6 e em Solaris, Linux e OS X.

• GCHisto

Esta pequena aplicação permite-nos detectar o comportamento do garbage collector visualmente. Requer que a aplicação seja executada com as flags -XX:+PrintGCTimeStamps e -XX+PrintGCDetails pois desenha os histogramas baseado nos logs do GC.

• JMap

Esta aplicação permite listar os objectos existentes na heap. Disponível na versão 1.4.2+ mas apenas em Solaris.

• JHat

O JHat permite, a partir de um binary heap file (que pode ser criado com o JMap), pesquisar por objectos na heap. Para tal, usa algo a que chamam OQL (Object Query Language), que não é mais que Javascipt com uns objectos especiais para pesquisar na heap. Está disponível a partir da versão 6 do JDK, sendo que para versões anteriores o projecto chamava-se simplesmente Hat.

• JConsole

A JConsole era a única aplicação que eu conhecia de todas as que foram faladas. Disponível desde a versão 1.4.2, permite consultar dados sobre memória, threads, MBeans e outras informações a partir de uma simples applet.

• Netbeans Profiling Tools

Incluído com o IDE Netbeans, vem este pacote de profiling tools que usa o motor JFluid para retirar dados de CPU, memória e threads. A integração com o IDE pareceu interessante embora não tenha sido demonstrada, mas pode-se marcar pontos de profiling como se se marcassem breakpoints directamente no IDE. Certamente a testar, com este hype todo à volta do Netbeans.

• VisualVM

O produto VisualVM foi o culminar da apresentação, o ponto a que eles queriam chegar. Inclui funcionalidades do JPS, JInfo, JStack, Jconsole e JStat. Além disso é extensível com plugins para o Btrace, GCHisto ou mesmo Glassfish ou Terracotta.

Java Persistense API 2.0

A sessão sobre JPA foi definitivamente a mais fraca dos dois dias até agora. Foi um debitar das alterações existentes na especificação do JSR 317 pela spec leader e muito pouco pedagógica. As pessoas ficaram com sono e não captei realmente nada assim de importante além da ideia que se está a complicar um bocado a coisas. Coisas como o Doctrine para php têm implementações bem fáceis de entender para os mesmos problemas, ou então a sessão conseguiu complica o simples.
O que valeu foi ter podido falar um pouco com o Michael Santos que além de Java Champion, é co-lead do JSR 310 (Date & Time API). Tive a oportunidade de ele referir as relações deste JSR como o de JPA, bem como o do J2EE 6 (JSR 316)que deverá também usar o JSR 310. Foi uma boa companhia para a sessão.

Transactional Memory in Java Technology-Based Systems

Esta foi provavelmente a sessão mais trabalhosa do JavaOne até ao momento. Foi apresentada por dois membros da Intel e um deles tinha um sotaque completamente russo o que tornou quase impossível perceber metade da apresentação. Foi no entanto bastante divertido pois sempre que ele falava saia 5% da sala.
A apresentação em si focou-se nos pontos de atomicidade que já tinha visto ontem nas apresentações de Fortress e do Brian Goetz. Falou-se memória transaccional por software (STM) e também por hardware (HTM), que desconhecia por completo. Dentro da STM, focaram o McRT que é o Multi-core runtime da intel que oferece funcionalidades de memória transaccional por software. Por enquanto apenas está disponível em C++, mas prometeram a versão para Java num dia de são nunca à tarde.

JSR 303: From a World of Constraints to Constrain the World

Sessão bastante interessante apresentado pelo leader do JSR 303, funcionário da JBoss. Falou-se sobre como e onde definir constraints no nosso modelo de domínio de forma a que seja independente de camada – uma validação deve ser homogénea desde a apresentação à base de dados.
O que esta especificação permite é a especificação de constraints de validação sobre beans/pojos de diversos tipos – simples e built-in, custom made, com dependências entre campos, etc. – e que fornece uma forma de cada camada poder executar as validações. Não define como essas camadas tratam o resultado das validações, portanto é bastante genérico, tem apoio de todos os quadrantes da indústria e rapidamente se vai tornar standard.
Além disso o speaker foi bastante acessível e simpático.

Comet: The Rise of Highly Interactive Web Sites

Eu já há bastante tempo que sei o que é Comet, o conceito é bastante simples: permitir que uma acção num cliente (tipicamente página web) seja reflectido em todos os clientes que estão na mesma vista sem que estes tenham que fazer nada. Mas não tinha a noção das diferentes aproximações do problema.
Esta sessão foi apresentada pelo Joe Walker do DWR, que explicou como o DWR usa o comet para fazer push de dados para o cliente; e pelo Alex Russell, o homem do Dojo Toolkit e do Cometd. Falaram de duas aproximações distintas: enquanto o DWR tem o Comet embutido e o push de dados para o cliente faz parte da lógica de apresentação da aplicação; o cometd é como que um servidor proxy, muito útil para aplicações já existentes pois os clientes ligam-se é ao servidor Cometd para receberem os updates.
Foi uma apresentação muito esclarecedora de duas pessoas que demonstraram serem mesmo os speakers ideais para o assunto.

Real World, Not Hello World: GWT Development for Java™ Technology Shops

Tinha planeado ir ver uma apresentação sobre JRuby pelo Ola Bini mas acabei por ficar na mesma sala para a apresentação seguinte. Por um lado, fiquei com menos entusiasmo pela as apresentações jruby depois do script bowl; por outro, conheci o Alexandre Gomes no jantar dos JUG Leaders e fiquei também para o ver a palestrar.
Esta apresentação foi tripartida: o Alexandre falou sobre GWT, um membro da equipa do IceFaces falou sobre o Comet deles e o líder do project Grizzly falou sobre o projecto em si e a integração com GWT.
Eu pessoalmente continuo a não estar totalmente convencido com a solução GWT mas estou a dar a oportunidade de ser surpreendido. O modelo de desenvolvimento à lá Swing com definição de layout e widgets no código java não me cai bem.
De qualquer modo, gostei bastante da apresentação do Alexandre e dos colegas dele.

No fim do dia, decidi ir até à festa de Eclipse onde supostamente havia cerveja gratis mas nada disso. Pelo caminho conhecemos um texano muito simpático que nos acompanhou numas cervejas e que pensava que Portugal era na América do Sul. Simpáticamente explicámos onde ficava no mapa o que mesmo assim não impediu que ele ficasse realmente envergonhado com a bacorada. Mas foi uma conversa excelente mesmo no que toca a empreendorismo.
O interessante da festa da eclipse foram na realidade 2 outros factos: em primeiro lugar, o director de marketing da Jetbrains, criadores do IntelliJ IDEA estava por lá, esse mesmo que oferece as licensas de IntelliJ que podemos distribuir nos eventos do nosso PT.JUG; também por lá estava o Rod Johnson, criador do Spring a assinar autógrafos e com raparigas giras à volta à procura de festa: é mais uma razão para participar em projectos open-source.

E assim foi, mais um dia cansativo mas a tentar aproveitar ao máximo a experiência do JavaOne.

Quantas vezes não nos queixámos de esta ou aquela feature no nosso IDE favorito, sem no entanto fazer nada para a melhorar. Ou aquele plugin que gostavamos mesmo de ter.
A Sun criou a Netbeans Innovators Grant que permite que membros da comunidade open-source ganhem dinheiro vivo com contributos para o projecto Netbeans. O que a Sun ganha são novas features implementadas para a plataforma a um custo bastante baixo e uma visibilidade pela publicidade que isto dos prémios por desenvolvimento atrai. Aliás, a jetbrains, criadores do fantástico IntelliJ IDEA, fizeram o mesmo há algum tempo atrás com sucesso.

Resumidamente, serão atribuídas as seguintes bolsas:

• 10x bolsas de $11.500 cada, para projectos “grandes”
• 10x bolsas de $2.000 cada, para projectos menores
• 2x gold awards no valor de $11.000, para atribuir a 2 projectos dos 20 anteriores que tenham muito sucesso
• 2x silver awards no valor de $5.000, para atribuir a 2 projectos dos 20 anteriores que tenham sucesso

Para isto será necessário ter boas ideias. Uma vez escolhidas as 20 ideias, são atribuídas as bolsas às mesmas sendo que só se recebe o dinheiro no fim, se o projecto for concluído com sucesso. Ou seja, não será dinheiro fácil.

A submissão de propostas dura até dia 3 de Março. Podem consultar mais detalhes no site do Netbeans.

Mesmo para gajos do Eclipse como eu isto pode vir a ser motivador

Sobre java especificamente, há poucos mais, que tenha encontrado. Mas no grupo do Java Posse tiveram um thread sobre podcasts e encontrei uns quantos interessantes que tenho ouvido e posso partilhar:

Software Engineering Radio

Temas diversos com uma aproximação por vezes académica, actuais e com convidados de renome também. Frequência semanal. Altamente aconselhado.

Drunk and Retired

Ambiente muito relaxado e com algum sentido de humor. Temas bastante actuais, fala-se sobre coisas como java, ruby, jquery, etc. Periocidade mais ou menos semanal.

FLOSS Weekly

Orientado a open-source em geral, pouco ou nada falam sobre java mas no nosso mundo não podemos estar sempre a olhar só para o nosso umbigo – também temos de olhar para o dos outros.
É cena para pessoal que não quer propriamente saber de IDEs e gosta mesmo é do vim ou do emacs, daquele pessoal que usa só roupa preta, barba e ouve metal Ás vezes tem convidados interessantes (já lá teve o criador da wikipedia, do php, do python, etc.) mas consegue ser sempre interessante.

E poucos mais conheço, agradecem-se sugestões!

1 – Criação da Base de Dados MySQL

Criem a base de dados com o nome lportal.

Poderão fazer isto utilizando o MySQL Administrator (a ferramenta de administração do MySQL) ou usando a seguinte linha de comando:
mysqladmin --default-character-set=utf8 create lportal

2 – Configuração do acesso à base de dados com o eclipse

Abram o Data Source Explorer do eclipse (Window -> Show view -> Data Source Explorer).

Seleccionem o icon ‘New Connection Profile’ ou usem o botão direito do rato do sobre ‘Databases’ e depois seleccionem ‘New’.

Na janela ‘New Connection Profile’ seleccionem o tipo SQL Model-JDBC Connection.

No quadro seguinte indiquem um nome para o perfil (ex: ‘Liferay – Mysql’).

No último quadro, usem o botão de procura (’…’) na lista “Select a browser”.

Adicionem uma nova definição:
• localizem o template para bases de dados MySQL na árvore (Database -> MySQL -> 5.0 -> MySQL JDBC Driver).
• Alterem as definições do driver:
  • Alterem o nome para ‘Liferay MySQL Driver’;
  • Removam o driver ‘default’ e adicionem um novo Jar correspondente ao ficheiro $WORKSPACE/ext/lib/development/mysql.jar ($WORKSPACE corresponde à localização da pasta do vosso workspace no sistema de ficheiros);
  • Configurem o valor das propriedades de acesso (username, password, etc…) tendo em atenção que o valor do ‘Database Name’ (e por consequência o final da linha do ‘Connection URL’ deverá ser ‘lportal‘.
• Confirmem as alterações e seleccionem agora este driver nas definições do driver (Database -> MySQL -> 5.0 -> Liferay MySQL Driver).

Voltem de novo à janela de criação do perfil e validem que todas as informações estão de acordo com a vossa configuração (podem testar a ligação a partir desta janela).

3 – Criação do modelo de dados

Editem o ficheiro create-mysql.sql na pasta /sql/create do projecto ‘ext’.
Caso não tenham memoria para desperdiçar (é o meu caso) respondam afirmativamente quando o eclipse perguntar se pretendem desligar a validação de sintaxe do ficheiro.

No topo da janela de edição do ficheiro encontram a configuração do ‘Connection profile’. Seleccionem o tipo Generic JDBC_1.x, o driver ‘Liferay - Mysql‘ e a base de dados lportal.

Nota: caso o status não seja ‘Connected‘ não vão conseguir ver o nome da base de dados.
Neste caso devem aceder ao Data Source Explorer ( Window -> Show View -> Data Source Explorer), seleccionar a Database ‘Liferay – MySQL’ e fazer connect (botão direito do rato)

Comentem as três primeiras linhas do ficheiro, uma vez que a base de dados já foi criada

-- drop database if exists lportal;
-- create database lportal character set utf8;
-- use lportal;

Gravem e executem o sql (ctrl+alt+X ou Execute All no menu contextual).

4 – Configuração do datasource no tomcat

Editem o ficheiro Root.xml localizado na pasta servers/tomcat/conf/Catalina/localhost do projecto ‘ext’.

Comentem o datasource do Hypersonic e descomentem o datasource do MySQL.

Preencham os atributos username e password e, caso não estejam a usar os valores default do MySQL, editem tambem o valor do atributo url, de acordo com a vossa configuração.

Gravem as alterações.

5 – Deploy da configuração para o servidor

Copiem o ficheiro Root.xml para a pasta conf/Catalina/localhost do tomcat.

Copiem e o ficheiro mysql.jar para para a pasta lib/ext do tomcat.

Voltarei a falar sobre a forma correcta de fazer deploy destes ficheiros no meu próximo artigo.

Precisei recentemente de instalar o ambiente de desenvolvimento. A documentação disponível refere-se à versão 4.2, está desactualizada e por isso contem bastantes incorrecções.

Como o processo não é lá muito intuitivo resolvi fazer uma lista dos passos necessários para concluir a instalação. Aqui fica:

1 – Instalar o Liferay Portal

• Comecem por fazer o download de um dos bundles do Liferay disponíveis no endereço http://www.liferay.com/web/guest/downloads. Eu optei pela versão recomendada, ou seja, com o Tomcat.
• Criem uma pasta no vosso filesystem para servir como base da instalação – $LIFERAY_HOME. Dêem-lhe um nome sugestivo como por exemplo ‘liferay-portal’.
• Dentro desta pasta, criem mais duas pastas, uma para conter a instalação do bundle do Liferay e outra para servir como workspace do eclipse (ex: $LIFERAY_HOME/tomcat e $LIFERAY_HOME/workspace).
• Descompactem o conteúdo do ficheiro do bundle para a pasta $LIFERAY_HOME/tomcat.

2 – Testar a instalação

• Executem o ficheiro $LIFERAY_HOME/tomcat/bin/startup.bat (ou startup.sh).
• Abram um browser e apontem para o endereço http://localhost:8080/. Se tudo estiver bem devem conseguir ver a página inicial do liferay-portal.
• Testar o login com as seguintes credenciais:
  [user]: test@liferay.com
  [pass]: test

3 – Importar o projecto para o eclipse a partir do repositório SVN

• Abram o eclipse.
• Criem um novo workspace na pasta $LIFERAY_HOME/workspace – $WORKSPACE
File > Switch Workspace > Other (indiquem a pasta $WORKSPACE e confirmem).
• Importem o projecto a partir do SVN : File > Import > SVN > Projects from SVN.
  • Como URL indiquem o endereço https://lportal.svn.sourceforge.net/svnroot/lportal.
  • Seleccionem o projecto ‘portal‘ e dentro deste o ramo ‘trunk‘.
  • Seleccionem a opção ‘Check out as a project with the name specified:‘ e indiquem como nome do projecto ‘liferay-portal‘.
  • Deixem a opção ‘Checkout recursively‘ seleccionada.
  • Aproveitem agora para fazer uma pausa enquanto o eclipse faz o checkout do projecto. No final deverá aparecer o projecto ‘portal‘ no Project Explorer do eclipse.

  Nota: Se tiverem problemas no checkout voltem a repetir os passos anteriores mas desta vez desseleccionem a recursividade (Checkout recursively). O checkout termina rapidamente. Depois usem a opção team syncronize/update para obterem o projecto completo. Isto permite ter mais controlo sobre a operação pois, neste caso, é possível interromper o processo a qualquer altura e retomar posteriormente desde o ponto onde ficou.

• Fechem o eclipse.

4 – Gerar e configurar o ambiente de desenvolvimento

Antes de dar inicio a este passo devem verificar se têm o ant 1.7.0 instalado. O build não funciona com versões anteriores.

O Liferay usa o Jikes como compilador default. Se o pretendem usar e ainda não o têm instalado, agora é a altura ideal para o fazerem .
No meu caso, a natural preguiça levou-me a optar pelo habitual javac.

• Abram uma consola de linha de comando na pasta $WORKSPACE/portal.
• Criem o ficheiro build.$USER.properties, onde $USER deve ser substituido pelo vosso username na máquina ou, alternativamente, o nome da própria máquina, com o seguinte conteúdo:
  lp.ext.dir=$WORKSPACE/ext
lp.eclipse.project.name=liferay-ext
javac.fork=true
javac.memoryMaximumSize=512m
javac.compiler=modern (ignorem esta se estiverem a usar o jikes e não se esqueçam de substituir $WORKSPACE pelo path correspondente).
• Executem o comando:
  ant clean start build-ext
• Aproveitem para fazer mais uma pausa .
  Após a conclusão do build, deve existir uma pasta ext no vosso workspace.
• Nesta pasta ($WORKSPACE/ext) criem o ficheiro
  app.server.$USER.properties onde, mais uma vez, $USER deve ser substituido pelo vosso username na máquina ou, alternativamente, o nome da própria máquina, e com o seguinte conteúdo :
  app.server.parent.dir= $LIFERAY_HOME
app.server.tomcat.dir=${app.server.parent.dir}/tomcat
  (se estiverem a instalar um bundle diferente devem consultar os nomes das properties no ficheiro app.server.properties).
• Caso não estejam a usar o jikes como compilador devem ainda criar o ficheiro build.$USER.properties, com o conteúdo:
  javac.compiler=modern
javac.fork=true
javac.memoryMaximumSize=256m

• Ainda na mesma pasta ($WORKSPACE/ext), executem o comando:
  ant deploy.
• Mais uma pausa (esta mais pequena).

5 – Importar o ambiente de desenvolvimento para o eclipse

• Voltem a abrir o eclipse.
• Importem o projecto ext (File > Import > Other > Existing Folder As New Project). Seleccionem a pasta $LIDERAY_HOME/ext.
• Devem ter agora dois projectos no vosso workspace – portal e ext.
• Seleccionem o projecto ext e acedam às suas properties.
• Seleccionem a tab ‘builders‘.
  • criem um novo builder (botão new).
  • Seleccionem o Ant Builder.
  • Nas propriedades do builder indiquem como buildfile o ficheiro build.xml que se encontra na pasta raiz do projecto ext ($WORKSPACE/ext).
  • De volta à tab ‘builder‘ desseleccionem o ‘Java Builder‘. O eclipse pede uma confirmação: aceitem!
• Se tiverem a opção de ‘auto-build‘ do eclipse activada, o eclipse deve dar inicio à compilação do projecto e… mais uma pausa.

6 – Configurar o ambiente de execução

• Acedam novamente às properties do projecto ext.
• Seleccionem a tab ‘Run/Debug Settings‘.
• No quadro ‘Create, manage and run configurations‘ seleccionem a opção ‘Run on Server‘ e depois o icon ‘new‘.
• Seleccionem a configuração ‘tomcat‘ (ou outra, dependendo do bundle que estão a instalar).
• Nas propriedades da configuração seleccionem a tab Arguments.
  • Substituam o valor dos argumentos
    -Djava.endorsed.dirs=${workspace_loc:ext/servers/tomcat/common/endorsed} -Dcatalina.base=${workspace_loc:ext/servers/tomcat}
-Dcatalina.home=${workspace_loc:ext/servers/tomcat} -Djava.io.tmpdir=${workspace_loc:ext/servers/tomcat/temp}
por
    -Djava.endorsed.dirs=${workspace_loc}/../tomcat/common/endorsed -Dcatalina.base=${workspace_loc}/../tomcat
-Dcatalina.home=${workspace_loc}/../tomcat -Djava.io.tmpdir=${workspace_loc}/../tomcat/temp

  • No ‘Working Directory‘ indiquem o path para o directorio ‘bin’ do tomcat ($LIFERAY_HOME/tomcat/bin).
• Ainda nas propriedades da configuração, seleccionem a tab Classpath
  • Removam a entrada que está marcada como erro (tools.jar).
  • Adicionem o bootstrap.jar do tomcat/bin como jar externo e removam a entrada existente para o mesmo ficheiro.
• Confirmem as alterações.
• Executem o projecto (Run). Devem ver o output do tomcat a ser dirigido para a consola do eclipse.

Confirmem que tudo está a funcionar seguindo os passos indicados no ponto 2. É claro que não precisam de executar o tomcat, o eclipse já tratou disso.

O próximo passo será configurar a base de dados, mas isso ficará para um outro post

Teremos, assim, um ambiente de desenvolvimento open-source, uma ferramenta de alta qualidade especializada para trabalhar com JSF, ADF, Seam e outros, e com especial cuidado à integração de componentes da família jboss. Destaca-se, especialmente, a atenção que será dada ao JBoss Seam, tecnologia que falarei num próximo post.

A Exadel, passa para um modelo de serviço e não de produtização, sendo que teremos a hipótese de contratar suporte. Os detalhes de como funcionará a parceria Red Hat / Exadel encontram-se neste post do Sacha Labourey, general manager da JBoss.

Isto são mesmo excelentes notícias. O Ajax4jsf é, pelo que ouvi falar, um bom produto para desenvolver ajax e Development Studio pode aumentar muito a produtividade, porque vai ter estas ferramentas todas integradas com wizards e coisas do género.