Campanha Ajude o Sr. Ping

A IBM está com uma campanha de marketing interessante onde o Sr. Ping (profissional de TI) vai viajar e perde o contato com sua equipe e seu projeto.
A idéia é que a cada dia o desenvolvimento de software se torna mais colaborativo e para manter tudo em ordem existe algo novo da brand Rational que pode ajudar. Para saber, veja a campanha:

http://www.viagemdosrping.com.br

Em breve vou postar mais detalhes sobre esse assunto…

Subscribe to this blog's RSS feed

Agora em outubro meu amigo Adriano Tavares da Squadra aqui de Belo Horizonte, junto com outros amigos da Squadra criaram o Pangea.
Segundo descrição do próprio grupo:

“Pangea é uma rede formada por profissionais e acadêmicos interessados no crescimento e evolução da arquitetura de software”.

http://pangeanet.ning.com

Se você trabalha com desenvolvimento de software, gosta de arquitetura, quer discutir, colaborar e aprender mais sobre o tema, não deixe de se cadastrar. Podemos aprender muito com as experiência e idéias de outras pessoas.

Alguns grupos dos quais participo:

- Monstros da Arquitetura de Software
- Domain-Driven Design
- O lugar certo para você aprender e praticar SOA

A rede hoje tem 93 membros e quanto mais gente participando melhor.

Exibir minha página em Pangea

Uma rede social com esse objetivo é muito melhor do que o orkut, né não?
Colabore!

O Rational Team Concert (RTC) foi o primeiro produto do projeto Jazz da IBM, que tem o foco em criar um ambiente mais colaborativo para o desenvolvimento de software - “People building great software, together” (slogan do projeto).
A primeira versão do RTC foi liberada dia 30 de junho e as primeiras impressões sobre ele são muito boas e podem ser encontradas facilmente em vários blogs.

Para quem nunca usou o RTC, ele possui fácil instalação (ao contrário de muitos softwares IBM), já trás embutido um controlador de versão e um controle de atividades similar ao JIRA (que é excelente). E além do foco colaborativo ele tem recursos fortes de Web 2.0.

Então o RTC está sendo uma boa resposta da IBM há algumas limitações do ClearCase (CC) / ClearQuest (CQ), que são softwares com mais de 10 anos. Apesar deu ter mostrado o lado bom do CC e CQ aqui no blog (post1, post2), muitas pessoas sabem que configurar e trabalhar com o CQ e principalmente o CC não é algo tão simples =)… é preciso alguém com um bom conhecimento sobre essas ferramentas.

Com o lançamento do RTC criou-se a dúvida: quem tem ClearCase, deve migrar para o RTC? E quanto a quem pretende usar o RTC e possui outros SCMs (Software Configuration Management) como o SVN e CVS?
A resposta sobre realizar a migração é depende.
Se estiver usando o CVS, certamente será necessaria a migração. Em compensação o RTC veio com suporte ao “legado” (se é que podemos falar assim) do SVN e ClearCase e eles ainda podem ser utilizados como o controlador de versão principal.
O único problema hoje é que o conector do RTC para o ClearCase / ClearQuest é apenas um “replicador” de dados. Ou seja: os arquivos criados no ClearCase são replicados para o controlador de versão do RTC. Então na prática os arquivos estão nos dois lugares.

Isso não é algo muito legal, e eu mesmo abri uma solicitação de melhoria em Agosto para o RTC delegar a responsabilidade de controlador de versão para o ClearCase em vez de replicar os dados, seria uma ponte real entre os dois softwares. A solicitação foi aprovada e acredito que será lançada nas próximas versões (existe uma discussão para ver se entra na versão 1.1 do RTC).

Mas qual a vantagem desse “bridge” ou conector entre o RTC e o CC, se o RTC já tem um controlador de versão?
Pelo que pude perceber da equipe dos projetos é que o ClearCase, ClearQuest e outros softwares da Rational vão receber influencias do Jazz e estarão cada vez mais alinhados com esse projeto. Então o controlador de versão do RTC continuará sendo distribuído como uma solução de fácil instalação e com recursos para a maior parte das equipes de desenvolvimento, e a integração com o ClearCase será uma opção mais robusta e com recursos não disponíveis no RTC como multisite e outros. Então o plano de migrar do ClearCase para o RTC hoje pode parecer fazer algum sentido por causa das limitações do conector disponível no RTC 1.0 (um replicador) e por aparentemente os softwares serem concorrentes, mas para o futuro talvez não seja a escolha correta dependendo do tamanho da equipe e dos recursos necessários. Manter o investimento no ClearCase e utilizar o conector ou bridge é a melhor no momento. A maior complexidade é justificável.

Em relação ao SVN depende da estratégia de cada equipe. O SVN é free. Não haveria perda de nenhum investimento ao migrar para o controlador de versão do RTC. O que pode ser feito é utilizar os dois juntos por um período de avaliação e depois realizar a migração dos dados para o RTC se for o caso, já que dificilmente o SVN terá mais features do que o controlador de versão do RTC e quanto mais softwares para “a mesma coisa”, maior a complexidade.

Nos próximos posts eu vou comentar algo sobre o Rational Quality Manager e Rational Requirements Composer que estão sendo desenvolvidos utilizando o Jazz.

Algumas imagens do RTC:

Antes de mais nada, as pessoas costumam confundir os nomes ClearCase e ClearQuest (ferramentas IBM Rational), afinal são nomes bem parecidos. Mas apesar destas ferramentas trabalharem de forma integrada (opcional), uma tem o papel totalmente diferente da outra.

Meu post anterior foi sobre o ClearCase (CC): Controladores de versão - ClearCase Base vs ClearCase UCM.

E aqui vamos introduzir o ClearQuest (CQ) e comentar o objetivo de integrar essas duas ferramentas.

Primeiramente para resolvermos o problema dos nomes parecidos, vamos imaginar que a sigla do ClearCase - CC é um C de Código - ela armazena código / arquivos, já que é um controlador de versão. E para o ClearQUEST, podemos dar atenção ao Quest que é “busca / investigação” - essa ferramenta entre outras coisas pode gerenciar bugs e um dos processos para resolver bugs é investigar, correto?

O ClearQuest é uma ferramenta que possui muita flexibilidade para automatizar workflows e seu maior uso é no controle de mudanças de software. Nele podemos cadastrar e acompanhar bugs, atividades, e controlar qualquer outro tipo de trabalho a ser realizado pela equipe.

Mas o que isso tem a ver com o ClearCase? Bom, já vimos anteriormente que o ClearCase UCM solicita uma atividade em cada check-in. Isso cria uma ligação do código do check-in com a atividade que o desenvolvedor está trabalhando.
A desvantagem nesta afirmação é que o controle de atividades do ClearCase é muito simples, já que esse não é o foco da ferramenta. No ClearCase uma atividade é composta apenas pelo título, não tem descrição, status do andamento, relatórios ou nada poderoso para gerenciamento. Bom, ai é que entra o ClearQuest: ele tem todos esses controles e mais um pouco. E caso sua equipe não esteja satisfeita, ela pode customizar os formulários, acrescentar campos, mudar status, alterar ações, estados e o workflow da solicitação. Isso faz do ClearQuest uma ferramenta excelente ferramenta mesmo sendo utilizada sem a integração com o ClearCase, e é uma das minhas preferidas do portfolio IBM.

Mas voltando ao assunto principal do tópico, associando uma atividade do ClearQuest em cada checkin de arquivos (resultado da integração das ferramentas) é possível ter um controle maior do projeto e do que e foi desenvolvido.
Exemplo:

• é possível manter a rastreabilidade de atividades do projeto para código, ou até ir mais além: usar a customização para criar um cadastro de caso de uso no CQ, relacionar o caso de uso com uma atividade do CQ e podemos extrair como informação todos os arquivos que foram alterados ou criados ao implementar determinado caso de uso. Esse é um dado importante para analise de impacto;
• algumas vezes não queremos buscar a última versão do código do controlador de versão porque ele contém partes de aplicativos que estão pela metade. Precisamos fazer um pacote com o produto, mas no ponto que queremos não existe nenhum label (marco importante). Então com essa integração uma opção é contruir esse pacote baseado nas atividades que queremos que esteja no pacote (ex: Implementação Caso de Uso 1, Implementação Caso de Uso 2, etc..).
• o GP tem maior controle de cada atividade do projeto. Sabe quais já foram iniciadas, em que o desenvolvedor está realmente trabalhando (são as atividades “alteradas” por último com os arquivos), e pode até fazer um script de métrica que calcule quantas linhas de código foram alteradas em cada atividade, para “sugerir” um esforço / custo por atividade.
• etc…

Então ligando o nosso produto de trabalho (documentos, diagramas, códigos) as atividades que realizamos no dia a dia, ganhamos um leque a mais de opções e dados que podem ser utilizados para melhorar o gerenciamento e qualidade do projeto.
Partes desses controles também são importantes em certificações com o CMMi.

Independente do processo de desenvolvimento de software adotado (RUP, desenvolvimento ágil, etc..), sua empresa certamente utiliza um software para fazer as gestão dos fontes de projetos. Entre os controladores de versão mais populares estão o CVS e SVN (gratuitos).  Atualmente eles são os softwares mais utilizados nesta categoria - certamente isso é impulsionados por projetos de software livre.
Talvez por este motivo, a maior parte das pessoas pouco sabe sobre outros softwares similares como o Rational ClearCase da IBM. Antes de mais nada, com certeza o objetivo deste post não é fazer propaganda, mas explicar (para quem quer conhecer) um pouco do ClearCase e a diferenças entre seus dois modos de projetos: Base e UCM. Para facilitar o entendimento, em alguns pontos do post, vou tentar fazer um paralelo com ferramentas mais populares - CVS, SVN.

Atualmente no trabalho divido minhas tarefas de Arquitetura de Software Java com suporte a instalação, configuração e utilização de ferramentas IBM Rational. Entre elas o ClearCase. Então vou dedicar uma parte dos meus posts a ferramentas IBM e o que elas podem agregar de valor em projetos.

Olhando do ponto de vista administrativo, o ClearCase possui N features e ferramentas que facilitam o gerenciamento de um projeto. Mas não vamos entrar nestes detalhes neste post. A idéia neste momento é olhar do ponto de vista de um usuário final (um desenvolvedor por exemplo).

Então, mãos a obra: conforme comentei o ClearCase permite criar dois tipos de projetos: Base e UCM.
Um projeto do ClearCase Base possui recursos similares ao SVN e CVS. Para esse “similar” entenda a presença dos conceitos e recursos básicos: check-in, check-out, branch, labels, etc…

Já no ClearCase UCM as coisas são um pouco diferentes. Além das funcionalidades do ClearCase Base, existem novos recursos e conceitos desconhecidos para muitas pessoas por estarem acostumadas somente ao mundo SVN / CVS, que são dois softwares excelentes e eu mesmo utilizo o SVN em meu projeto de Software Livre.

No ClearCase UCM (Unified Change Management) exitem três palavrinhas chave que fazem muita diferença: Stream, Rebase e Delivery. Elas vão nos forçar a trabalhar de uma outra maneira com o código fonte do produto.

Para explicar essas diferenças no momento de utilização da ferramenta vou fazer um paralelo entre dois termos: Branch e Stream.

Um branch a maioria de nós conhecemos. É uma ramificação no controlador de versão do fonte do nosso projeto (main). Essa ramificação é muito utilizada para realizar manutenções evolutivas e correções no software.
Vejamos a figura abaixo:

Como o branch força o trabalho da equipe em área separadas, ele pode evitar que o código parcial de uma manutenção evolutiva (que está sendo implementada a algumas semanas) vá por engano para homologação/ produção junto com a correção de um bug simples aberto e corrigido nas últimas horas.

Mas o branch não evita um problema comum do desenvolvimento de software empresarial (que geralmente não tem a figura de commiters): a quebra do build ou funcionamento interno (em desenvolvimento) do aplicativo. Se uma pessoa fizer algo errado e realizar o check-in, essa pessoa pode impactar o trabalho de outras pessoas, mesmo em projetos com testes unitários. Um software de integração continua não evita esse problema porque geralmente ele realiza o build do que já está no controlador de versão, e mesmo assim ele não consegue validar todos os tipos de problemas (como em XMLs). Então sempre há um jeito de atrapalhar o trabalho de outro desenvolvedor com um check-in equivocado =P

Para evitar isso o ClearCase UCM existe a opção de utilizar o que é chamado de desenvolvimento em paralelo que é um pouco diferente do conceito do CVS / SVN ou mesmo ClearCase Base.
No ClearCase UCM o cenário de qualquer projeto em equipe teria essas características:

• cada desenvolvedor que conectar ao projeto, terá automaticamente um “branch” exclusivo para trabalhar - no UCM esse “branch” é chamado de stream;
• o check-in de um desenvolvedor não causa impacto em outro desenvolvedor porque cada desenvolvedor trabalha na sua stream;
• todo check-in é relacionado uma atividade então é possível relacionar o código com atividades do projeto;
• entre outros…

Estes são apenas algumas características do ClearCase UCM, mas a partir delas já podemos entender como é diferente a maneira de utilizar. Vantagens? Vejamos:
Com streams separadas para os desenvolvedores um desenvolvedor não impacta no trabalho de outro. Após um desenvolvedor realizar vários check-ins de “código parcial” para a mesma atividade. Ao acabar de implentar uma determinada funcionalidade, ele fará um Delivery (entrega) da atividade. Nesse momento todos vão poder ver a implementação deste desenvolvedor através do que é chamado de Stream de Integração.
Mas calma, ainda não é possível baixar para a sua Stream a implementação de outro desenvolvedor. Isso acontece porque ainda sim, mesmo dizendo que terminou a atividade o desenvolvedor pode ter feito algo errado, e isso poderia quebrar o seu build. Então o fluxo da ferramenta agora é a validação da Stream de Integração (seja com ferramentas de integração continua ou testes funcionais) e depois a promoção de atividades liberadas pelo desenvolvedor na stream de integração para uma baseline. A partir desse momento qualquer pessoa pode baixar a última versão do código para sua stream (operação chamada de Rebase), afinal o que está na baseline é o fonte correto.

Alguns desses conceitos como baseline são conceitos de Configuration Management (CM) ou Gerência de Configuração, e é dai que vem o nome UCM do ClearCase - Unified Configuration Management. É uma ferramenta construída e baseada nas melhores práticas de CM. Não é atoa que muitas vezes é citada por consultores de CMMi ou MPS.br.

Para completar, segue alguns conceitos de termos novos (considerando o SVN / CVS) que vimos neste post:

• Stream: em poucas palavras pode ser entendido como um branch integrado a atividades, e geralmente as stream são separadas por desenvolvedores e existe uma de integração - o que não acontece em branchs do SVN, CVS ou ClearCase Base;
• Delivery: é a entrega do código de uma atividade para a stream de integração;
• Rebase: representa a atualização da sua stream de desenvolvimento a partir de uma baseline;

Até a próxima!

Eu estava viajando, então estive ausente do PC por alguns dias
De volta agora é hora de colocar o assunto em dia.

Em dois posts anteriores eu falei algo sobre JMS. Um que tratava da integração do Oracle com Java e outro da comunicação do Websphere MQ via JMS. Então para completar o assunto vou mostrar na prática como enviar e receber mensagens usando JMS e Spring.
Provavelmente esse post vai ser melhor aproveitado por quem já conhece ou utiliza o Spring, mas como é um framework popular é fácil encontrar referencias sobre suas configurações na web.

Connection Factory:

Nosso objetivo é enviar mensagens via JMS para o Websphere MQ (MQSeries), dando seqüencia ao post Websphere MQ e JMS. Para isso vamos usar o Connection Factory da IBM com.ibm.mq.jms.MQQueueConnectionFactory para gerenciar a conexão. Segue abaixo o trecho de configuração disso no Spring (arquivo applicationContext.xml):

<bean id="jmsQueueConnectionFactory" class="com.ibm.mq.jms.MQQueueConnectionFactory">
	<property name="hostName">
		<value>${mq.hostName}</value> 
	</property>
	<property name="queueManager">
		<value>${mq.queueManager}</value>
	</property>
	<property name="channel">
		<value>${mq.channel}</value>
	</property>
	<property name="port">
		<value>${mq.port}</value>
	</property>
	<property name="transportType">
		<value>1</value>
	</property>
</bean>

Esse transportType é referente ao tipo de comunicação utilizado. O valor 1 é referente a constante  com.ibm.mq.jms.JMSC.MQJMS_TP_CLIENT_MQ_TCPIP que diz que a comunicação é via TCP IP.

Configuração:

As demais configurações do Spring para JMS são simples, e similares a isso:

<bean id="jmsSpringConnectionFactory" class="org.springframework.jms.connection.SingleConnectionFactory102">
	<property name="targetConnectionFactory">
		<ref local="jmsQueueConnectionFactory" />
	</property>
</bean>
 
<bean id="jmsQueueTemplate" class="org.springframework.jms.core.JmsTemplate102">
	<property name="connectionFactory" ref="jmsSpringConnectionFactory"/>
	<property name="pubSubDomain" value="false"/> <!-- false seta para queue (point to point) -->
	<property name="receiveTimeout" value="500"/>
</bean>

Utilização:

Para usar é muito simples, basta instanciar o Spring e depois enviar e receber mensagem com praticamente uma linha de código.

Instanciando o Spring:

BeanFactoryLocator bfs = SingletonBeanFactoryLocator.getInstance("applicationContext.xml");
BeanFactoryReference bf = bfs.useBeanFactory("mqSpring");

O Spring irá instanciar as classes configuradas nos beans, e a partir dai é só usar.

Enviando mensagem:

JmsTemplate jmsTemplate = (JmsTemplate) bf.getFactory().getBean("jmsQueueTemplate");
jmsTemplate.convertAndSend("fila", "mensagem");

Recebendo mensagem:

JmsTemplate jmsTemplate = (JmsTemplate) bf.getFactory().getBean("jmsQueueTemplate");
TextMessage textMessage = (TextMessage) jmsTemplate.receive("fila");

Listener:

Uma outra opção para receber mensagens do MQ é criar um listener que fica escutando uma determinada fila e irá receber automaticamente novas mensagens.

<bean id="messageListener" class="br.com.globalvalue.exemplomq.ExemploListener" />
 
<bean id="jmsListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
	<property name="connectionFactory" ref="jmsSpringConnectionFactory"/>
	<property name="messageListener" ref="messageListener" />
	<property name="destinationName"><value>${mq.queue.inbox}</value></property>
</bean>

public class ExemploListener implements MessageListener {
	public void onMessage(Message message) {
		if (message instanceof TextMessage) {
			try {
				System.out.println(((TextMessage) message).getText());
			}
			catch (JMSException ex) {
				throw new RuntimeException(ex);
			}
		}
		else {
			throw new IllegalArgumentException("Message must be of type TextMessage");
		}
	}
}

Para executar o código é necessário os jar`s do Spring (e dependencias) e os jar`s da IBM para o Websphere MQ. Espero que o nível de detalhes tenha sido suficientes. Vimos que se o projeto utiliza Spring é fácil enviar e receber mensagens utilizando JMS, mesmo com classes (Factory) de terceiros como no caso do nosso exemplo para Websphere MQ.

Existem várias formas de realizar comunicação entre aplicações. Entre elas estão: troca de arquivos,  compartilhamento de banco de dados, chamada de métodos remotos (RMI, SOAP) e mensageria.

O MQ (Message Queue) é um padrão para mensageria adotado por várias empresas, entre elas a IBM que possui o produto Websphere MQ (antigamente chamado de MQSeries).

Um dos pontos fortes do MQ se comparado com outras tecnologias é a troca de mensagens assíncronas e garantia de entrega. Ou seja: conseguimos enviar uma mensagem para a fila de um aplicativo sem que este aplicativo esteja no ar e sem ficar parado esperando uma resposta (comunicação assíncrona). Temos ainda a certeza de que se a mensagem saiu da fila é porque ela foi lida (entregue).
Uma comunicação como esta é muito mais segura do que um envio de e-mail, troca de arquivos ou transferências de dados similares.

Um detalhe importante é que apesar da comunicação ser assíncrona, é possível utilizá-la de forma online - onde enviamos e recebemos a resposta em “tempo real”. Vou explicar neste post como isso funciona. Alias, já vi implementações que tentam dar essa aparência de comunicação online realizando pooling (loop) nas filas do MQ para verificar se existem novas mensagens. Mas isso não é o procedimento correto. O MQ permite que a aplicação assine uma fila e receba novas mensagens automaticamente sem perder tempo no pooling ou degradar o ambiente.

No caso do Websphere MQ podemos realizar a comunicação de duas maneiras: a primeira é utilizando o Websphere MQ Client que possui uma API para programação em C, Cobol, CPlus, .Net, Java e VB 6. E outra forma bastante útil para o pessoal de Java é utilizando JMS (Java Message Service). O produto Websphere MQ suporta JMS, e neste caso não é necessário instalar ou utilizar o Websphere MQ Client.

Como este é um blog sobre Java vamos citar alguns detalhes da comunicação usando JMS.

Olhando a arquitetura do JMS existem maneiras diferentes de realizar a interação com uma fila (queue).
A primeira é uma comunicação ponto a ponto onde a aplicação 1 envia mensagem para uma fila e somente a aplicação 2 irá ler. Vejamos a imagem abaixo:

Neste modo ponto a ponto, quando a aplicação 2 ler a mensagem via JMS o próprio protocolo irá enviar um acknowledge para a fila (comportamento padrão) e a mensagem será apagada pelo MQ (leitura ocorreu com sucesso).

Se pararmos para pensar esse modo não funcionará caso seja necessário enviar a mesma mensagem para mais de uma aplicação. Outro problema de partir do cliente a requisição de mensagens é que ele teoricamente tem que fazer pooling, verificando de tempos em tempos se existem novas mensagens na fila.

Se for necessário contornar essas limitações existe uma outra forma de comunicação, que é a Publish and Subscribe. Onde vários aplicativos podem assinar uma vila e receber as mensagens quando chegarem. A mensagem só será apagada da fila quando todos receberem.

Um detalhe interessante é que as mensagens não precisam ser necessariamente do tipo texto. O JMS suporta os seguintes tipos de dados: text, map, bytes, stream, e object. O stream é uma boa opção para mensagens muito grandes (enquanto uma ponta está enviando a mensagem a outra já pode ir recebendo), enquanto o tipo object está mais próximo de linguagens orientadas a objeto.

Bom, basicamente é assim que funciona. Nós próximos posts vou tentar mostrar alguns passos de como escrever uma aplicação que envie e receba mensagens via JMS.

Atualmente estou atuando em um projeto onde é necessário a integração do Oracle com Java. Ou seja: é necessário executar código Java dentro do Oracle para uma determinada funcionalidade.

Esse projeto faz parte de um treinamento/consultoria sobre Websphere MQ (antigamente chamado de MQSeries) para um cliente, e vai ser o primeiro tema / “puxão de orelha” depois da reformulação do blog.

Puxão de orelha porque alguns itens referentes a integração do Oracle com Java não são legais. Mas para entender o problema e o funcionamento da integração vamos a um rápido cenário do aplicativo:

Além do treinamento de Websphere MQ o cliente solicitou que fosse desenvolvido um conector MQ em Java para posteriormente ser utilizado pelo sistema deles. Então optamos por desenvolver o conector MQ usando JMS e abstrair toda a complexidade da comunicação. Ele iria enviar mensagens com um comando e receber mensagens com um comando a partir do aplicativo Java. Até esse ponto estava excelente.

A dificuldade começou quando o cliente solicitou que o Conector MQ fosse executado dentro do Oracle através de uma trigger já que o Oracle suportava Java. Realmente o Oracle suporta Java, mas não tão bem como era esperado.
Somente para deixar claro: classes Java simples (recursos nativos da JVM) rodam muito bem no Oracle, isso foi um ponto bem positivo. O problema é executar uma aplicação ou conector que tem vários jars como API.

Objetivamente seguem detalhes sobre pontos problemáticos do Oracle versão 10.2:

• ele não aceita jar’s externos. Todos os jar’s devem ser carregados para o banco usando o comando loadjava.
• o comando loadjava carrega as classes do jar mas deixa todas com status INVALID !?!?… a maneria de resolver isso é usar o comando loadjava com o parâmetro “-resolve”.
• o problema do parâmetro “-resolve” é que ele tenta “re-compilar” todas as classes do jar (sendo que um jar já é algo pronto para utilizar). Para cada classe o Oracle solicita as dependências (classes que estão no import). Então para incluir um jar de um driver do MQ preciso de N outros jars para satisfazer as dependências de compilação;
• uma forma de resolver o problema acima podemos até utilizar o parâmetro “-genmissing” do comando loadjava, ele vai gerar uma classe fake para cada dependência e evita problemas de compilação, mas é obvio que se a classe fake for usada em qualquer ponto do processo (direta ou indiretamente) vai dar erro (ORA-29532: Java call terminated by uncaught Java exception: java.lang.NoClassDefFoundError:
  !!!ERROR!!! generated by genmissing) - então o genmissing não é muito útil, somos obrigados a ter as dependências para compilar / resolver quase tudo usando o “-resolve”;
• o Oracle carrega para dentro do banco a classe que queremos importar + todos os jars necessários para execução + todas as dependências. Então temos um excesso de classes desnecessariamente;

Por causa dessas limitações a integração do Oracle com Java não é tão transparente. Não acredito que isso tenha um tratamento melhor no Oracle 11. Apesar do banco Oracle não ser um Application Server, poderia pelo menos seguir a arquitetura Java e ler as libs de um CLASSPATH. A parte de ter que carregar os jar para dentro do Oracle e re-compilar matou parte do suporte a Java do banco. Esse trabalho todo não vale a pena

Então esse foi o puxão de orelha, e todos esses problemas foram suportados pelo suporte oficial Oracle (http://metalink.oracle.com).

Mas em tempo, o SQLJ é bastante poderoso: podemos escrever uma classe Java (usando recursos nativos) e em determinados pontos utilizar #sql() (querys) com váriaveis Java. Então considerando somente esta necessidade a utilização é válida.

Bom o projeto está indo bem, a cada dia novas melhorias. Está dando muiiito trabalho, mas está ficando bacana.

O curioso é que o país onde as pessoas mais interagem e sugerem as coisas é a Índia =) O pessoal lá parece ser muito ligado na área de desenvolvimento mesmo.

Fora um ou outro bug a versão 1.0.0-M3 trás 15 melhorias enquanto a 1.0.0-M2 tinha 7. E cada melhoria dessas são significativas, então essa é uma boa release. Espero ter tempo para dedicar a JSF logo e adicionar essa opção no template da ferramenta até porque meu interesse pessoal é mais por JSF por enquanto.

Como detalhamento segue o changelog:

——————————————-
Version 1.0.0-M3 (2008-05-25)

Bug
* [Template] - Acertos no template para Struts - cruds com campo date, javascripts e outros.
* [Template] - Resolvido problema na geração da pasta /jsp/velocity usada para o struts-menu.
* [Plugin - Core] - Quando algum package tinha o mesmo nome do projeto o mapping gerava as classes na pasta errada.

Improvement
* [Plugin - Core] - Distribuição do plug-in usando jar e em arquivo separado do template.
* [Plugin - Core] - Adicionada validação de compatibilidade entre o template e o plug-in.
* [Plugin - Core] - Criação de aba exclusiva para gerenciar templates.
* [Plugin - Core] - Melhoria de performance do build.
* [Plugin - Core] - Adicionado botão para selecionar todos os atributos de uma classe no CRUD.
* [Plugin - UI] - Novo wizard para abrir o SPIDER Editor.
* [Template] - Mais traduções para o i18n do projeto.
* [Template] - Criado atributos para armazenar um resumo das características de cada template.
* [Template] - Adicionado ao template a possibilidade de executar scripts ant para completar o build.
* [Template] - Utilização da feature de executar scripts ant para rodar o xdoclet-build.xml após a geração de CRUDs com Struts.
* [Template] - Alinhamento do código HTML das páginas jsp geradas.
* [Others] - Utilização do Atlassian Bamboo como software de integração contínua e do Fisheye.
* [Others] - Criado um Eclipse Update Site para instalação e atualização do plug-in.
* [Documentation] - Site: tradução de mais páginas para o idioma inglês (mais documentação).
* [Documentation] - Nova sessão “Getting Started” no site.

——————————————-

http://www.j2eespider.org

Parece estranho mas sábado dia 26 vou pegar carona em um evento do pessoal de .Net (Microsoft) e fechá-lo com uma palestra Java sobre o projeto J2EE Spider.

Como o povo do MG-JUG está um pouco parado em relação a palestras, vai ser uma oportunidade de ter algo sobre Java por aqui.

O evento vai ser o dia todo, mas a palestra do SPIDER será na parte da tarde por volta das 15:30h.

A palestra é mais um bate papo sobre geração de código e apresentação da ferramenta.

Quem quiser chegar antes, desde as 9h tem palestras sobre tecnologias da Microsoft inclusive SilverLight que é concorrente do Java FX.

Até lá!