Já faz um mês que o OSGi 4.2 foi lançado(Escrito anteriormente na InfoQ). O que vem acontecendo desde então?
Bem como o lançamento no início deste ano do Equinox 3.5 que implementou as especificações draft do OSGi, o Apache Felix 2.0 foi recentemente lançado com suporte a OSGi 4.2. Além disso, o Knopflerfish 3.0 beta que foi lançado ontem também implementa o núcleo 4.2, exceto para o framework launcher que ainda está em desenvolvimento.
O Apache Karaf 1.0 foi construído sobre o core framework e foi lançado há duas semanas. Este pretende ser um mecanismo agnóstico de distribuição de um framework OSGi com vários bundles úteis já empacotados, como o Blueprint, provisioning, logging e acesso remoto (via SSH). Para os novatos em OSGi, esse pode ser um bom ponto de partida para utilizá-lo, já que é um pacote completo, bem como nas distribuições Linux baseadas no Kernel padrão para fornecer funcionalidades adicionais ou de gestão.
A SpringSource (agora da VMware), recentemente lançou o dm Server 2.0M5, incluindo o módulo dm Kernel, que além de proporcionar a implementação de referência do OSGi para o serviço Blueprint (abordada anteriormente pela InfoQ), também utiliza um recurso chamado nested frameworks (frameworks aninhados). Este foi um adicional proposto para o OSGi 4.2 que foi deixado de lado para que mais experiência fosse reunida para um futuro lançamento, este permite que um framework OSGi possa criar um framework interno (ou região na terminologia do dm Server) para uma aplicação específica. Isso permite que múltiplas aplicações sejam instaladas e separadas de outros frameworks do sistema. A experiência adquirida com isso, sem dúvida, será aproveitada no planejamento da próxima versão do OSGi.
A versão 7.0 do Jetty foi recentemente liberada(conforme coberto pela InfoQ) e atua como um Java web engine independente que pode ser utilizado em outros aplicativos (OSGi ou Java tradicional). A Oracle também anunciou o roadmap do WebLogic que inclui o processo em andamento da Microservice Architecture baseada em OSGi. Por último, a Sun desenvolveu o servidor GlassFish, o GlassFish V3 Preview, baseado em OSGi que está disponível para download.
O OSGi Enterprise Expert Group está trabalhando para a definição de um conjunto de serviços OSGi (por exemplo, para resolver JNDI e Binding de Servlets) e já definiu os serviços OSGi remotos, que serão parte da especificação 4.2. O grupo de peritos (expert-group) tem como objetivo lançar uma nova versão no início do ano que vem, mas parece que atualmente cada um dos principais servidores de aplicação já estão baseando suas runtimes em OSGi.
Executar sistemas OSGi é bem simples, mas construí-los ainda é um desafio. Considerando que soluções como Ant normalmente lidam com um classpath plano, assim como a visibilidade completa de pacotes públicos, o OSGi runtime fornece um classpath mais modular (em tempo de execução e logo, implicitamente, em tempo de compilação também). Ferramentas existentes como o Eclipse PDE funcionam bem para casos específicos (por exemplo, para criação de plugins para o Eclipse), mas tendem a não funcionar bem para IDE agnóstica ou builds sem cabeçalhos em layouts personalizados. Existe progresso em outros build engines, como o Apache Sigil, baseado em Ant/Ivy e visa apoiar não só o Eclipse, mas também o NetBeans OSGi. Embora ainda em incubação, recentemente tornou-se auto-construtivo e uma versão completa está prevista para o final do ano.
Pax Construct tornou-se uma forma indispensável de construir builds baseados em Maven, através de uma combinação com a ferramenta bnd, que também é usada pelo Felix maven bnd plugin. Fala-se até de fazer artefatos Eclipse em um repositório Maven o que ajudaria aqueles que queiram criar builds baseados em Maven e utilizar bundles baseados no Eclipse. No entanto, é provável que este vai estar disponível inicialmente apenas para um pequeno subconjunto de projetos que demonstrará a relação benefício/necessidade de tal sistema.
O Eclipse, entretanto, está centrado na construção de um outro projeto [AZ][0-9], desta vez chamado B3. Isso não vai mudar substancialmente a forma como são construídos os projectos do Eclipse, mas irá aliar o build atual do PDE com outros builds/deployment systems como os baseados em Buckminster e Hudson.
Embora o NetBeans ainda permaneça ligeiramente excluído do OSGi, builds do netisgo (que oferecem suporte ao NetBeans OSGi) ainda estão em andamento. Por outro lado, o IntelliJ 9,0 Preview que foi recentemente lançado, inclui suporte OSGi, tanto na versão Community quanto na Ultimate (embora seja um download separado para a versão Community).
O Eclipse 3.6M2 já está disponível há algumas semanas, e fornece um marco da próxima versão da plataforma Eclipse. O suporte ao Equinox também inclui o OSGi EventAdmin, que está sendo mais fortemente utilizado no desenvolvimento do suporte assíncrono da plataforma OSGi. (O Equinox previamente ofereceu o EventAdmin como um bundle separado para download, o que significa que alguns nunca o usaram; incorporando-o no RCP, estará disponível por padrão em mais locais e, assim, será mais usado no futuro.) O Equinox 3.6M2 traz também a capacidade de fazer classloader-weaving nos bundles, usando AspectJ para injetar código em tempo de carregamento (loadtime). Além disso, o Equinox console aceita múltiplas sessões, permitindo assim que vários usuários conectem simultaneamente a uma instância remota.
Também novo no mundo das ferramentas é E4 Eclipse 1.0M1. O Eclipse E4 é uma verão assíncrona da plataforma Eclipse dentro de um JavaScript runtime, assim como um navegador web. Muitas das ações subjacentes no Eclipse 3.x são síncronas, que significa que as ações do usuário bloqueiam a interface. Para suportar clientes remotos, as ações estão sendo reformuladas para suportar o acesso assíncrono e, o plano é unir isso tudo futuramente no Eclipse 3.x. Uma das funcionalidades oferecidas é a capacidade de criar OSGi bundles em JavaScript puro; o wiki E4/JavaScript dá mais detalhes sobre como isso funciona usando o JSFramework e objetos JSConstants. Há um novo e notável para a versão E4 1.0M1.
A temporada de conferências dos próximo seis meses, terá OSGi particularmente bem representado. A primeira conferência será na próxima semana, a SpringOne América, que terá os resultados da pesquisa Burton Group 2nd Annual Survey OSGi (por favor, reserve um momento para preenchê-la antes de 19 de outubro, se ainda não a tiver preenchido). Em seguida haverá a EclipseCon Summit Europe no final do mês e, em seguida a QCon SF no próximo mês. No ano que vem haverá a OSGi DevCon Londres 2010 em janeiro, a QCon Londres no início de março, e a EclipseCon 2010 na Califórnia.
Os Grupos de Usuários OSGi continuam indo bem, a recente OSGi in Anger por Tara Simpson da Instil Software realizada na Paremus discutiu a experiência de um sistema de telecomunicações que utiliza OSGi, a fim de gerenciar o sistema remotamente e utilizar prestação de serviços em nós. Dada a conversa que seguiu para o bar (patrocinado por Luminis), parecia que foi bem aceito. A apresentação e vídeo, gravado por SkillsMatter, estão disponíveis na página do encontro. Um tema recorrente deste tipo de projeto é que a passagem de um sistema aparentemente modular para OSGi ajuda a identificar onde pacotes vazaram; O Jetty descobriu o mesmo quando se mudou para o Eclipse. Além disso, uma vez que estes sistemas tenham mudado para OSGi é difícil imaginar como voltar para a construção de sistemas complexos sem OSGi.
Mas e enquanto ao Simple Module System, que visa a criação de um meio de campo entre o OSGi e o projeto Jigsaw? Embora inicialmente promissor, não há diferença de opiniões quanto a saber se o espaço de runtime deve ser em classpath flat (como está o Java no momento) ou nestead classpath (como no OSGi e no compile path). Uma futura chamada a um expert group pode ajudar, mas ainda não parece ter acontecido. Neil Bartlett vai falar sobre isso em Londres dentro de duas semanas, em Modularidade: uma visão a partir da galeria.
A InfoQ está publicando uma série sobre modularidade Java, o próximo artigo da série será publicado na semana que vem.