Na última conferência para desenvolvedores da OSGi realizada em New York, a OSGi Alliance lançou o core do release 6. Este release mantém compatibilidade retroativa com o release 5 de 2012 e foi implementado no Eclipse Luna através do plugin Equinox.
A especificação lista novidades e adiciona pequenas alterações em dois novos recursos:
- Objetos para transferência de dados provê meios de representar o estado de um objeto de dentro do framework da OSGi;
- Versionamento por anotações para declaração da versão do pacote e se as interfaces são consumidoras ou produtoras;
- Namespace nativo fornecem o padrão osgi.native para atender a capacicidade genérica;
- Extensões BundleActivators foram adicionados para permitir a participação na inicialização e desligamento do framework.
Os objetos para transferência de dados são atrelados a classe org.osgi.dto.DTO. Cada subclasse tem diversos atributos comuns de mapeamento para o objeto OSGi subjacente. A intenção destes objetos é fazer a captura instantânea de um determinado estado do sistema de forma independente de seu provedor permitindo que estes dados sejam transportados de uma rede para um local remoto de forma serializada. O acesso ao DTO é concluído quando o método adapt() e disparado no objeto de estrutura subjacente com o nome do tipo de DTO necessário:
BundleDTO bdto = bundle.adapt(BundleDTO.class).
Infelizmente, apesar de ser um objeto de dados, a classe DTO não é serializável e, por isso, não pode ser utilizado com os métodos padrão de serialização do Java. No entanto, bibliotecas como o GSon podem ser usadas para converter os objetos de dados para um formato que pode ser enviado através da rede. Há um método chamado toString que pode ser um meio para depurar o conteúdo do objeto, mas não pode ser utilizado para fazer a interoperabilidade. No entanto, é provável que interfaces de gestão remota serão beneficiadas pela especificação DTO para adquirir o estado de uma estrutura OSGi remota e apresentá-la através de uma interface de consumidor.
Os exemplos DTO são destinados apenas para leitura instantânea; não existem métodos ou maneiras de manipular o framework com base nas mudanças de estado.
O versionamento por anotações provê um meio para identificar se uma interface será utilizada ou implementada pelos clientes. Interfaces anotadas com @ProviderType estão previstas para serem utilizadas pelos clientes, mas sem implementação - equivalente à @noimplement usado pelo Eclipse. Interfaces anotadas com o @ConsumerType destinam-se a ser implementadas pelos clientes.
Ferramentas podem ler as anotações (que ficam nos arquivos de classe, mas que não são usadas em tempo de execução) e fornecer informações de aviso ou erro com base na versão de numeração semântica. Adicionar métodos para interfaces que são anotados com @ProviderType exige a atualização do pacote ou a utilização de uma versão menor, uma vez que é compatível com versões anteriores; no entanto, a adição de métodos a interfaces anotados com @ConsumerType estão quebrando alterações que necessitam do número da versão principal a ser incrementado.
Uma anotação adicional é o @Version especificando qual pacote será retido como pacote de nível (para ser utilizado nos arquivos de informação do pacote), que pode ser processado por ferramentas para gerar a informação de número de versão apropriada.
As anotações são fornecidas por um JAR independente, osgi.annotations, em vez da própria estrutura do núcleo do framework. Como resultado, o código que deseja usar essas anotações deve adicionar um JAR em vez de usar uma implementação core do framework. Uma vez que as anotações do JAR não estão dentro do pacote (não tem nenhum cabeçalho Export-Package no arquivo META-INF / MANIFEST.MF) e não pode ser resolvidas nas classes através da construção PDE que usam os nomes de pacotes para conectar-se com as dependências. Em vez disso, tem de ser adicionado como uma dependência no classpath, ou marcar no repositório como o framework Equinox faz. No momento da escrita, os JARs OSGi não está disponíveis no Eclipse Luna, e é provável que os usuários continuem usando a anotação @noimplement do JavaDoc.
O namespace osgi.native fornece um meio para codificar os elementos "require-capability" e "provide-capability" dentro do pacote para que as dependências possam estar conectadas. Isso não substitui o cabeçalho Bundle-NativeCode; No entanto, o framework converte as restrições especificadas no Bundle-NativeCode em um conjunto de requisitos e provisões agrupadas no osgi.native.
O framework acrescentou um conceito sobre o ExtensionBundle-Activator. Isso permite que um pacote possa ser ligado na inicialização e desligamento do framework, desde que seja declarado como uma extensão (com Fragment-Host: system.bundle; extension: = framework). Isso implementa o padrão da interface BundleActivator, mas é especificado para extensões do framework.
O Release 6 da OSGi também adiciona algumas pequenas alterações para os objetos existentes; as classes do Framework ganharam um método init que possui um número variável de FrameworkListeners; FrameworkWiring adiciona um novo método e um novo findProviders e um novo WovenClassListener foi adicionado.
Para mais informações sobre o Release 6 do "core" OSGi, consulte as especificações no site da OSGi. A OSGi Alliance também está trabalhando em um conjunto de ferramentas chamado En Route; O InfoQ.com entrevistou recentemente Peter Kriens sobre o assunto.