Automação RPM + OSGi: passo 1 – completo

Versões recentes de RPM incluem o conceito de geradores de dependência. Isso abre a porta para uma série de automações e simplificações para as pessoas que utilizam RPM como seu formato de distribuição.

No Fedora, nós entramos em cena e trabalhamos para tornar o Java menos estranho em distribuições Linux.

Nem todos os recursos OSGi são levados em conta, porque alguns deles não correspondem aos objetivos de distribuição de um único projeto. Tudo é baseado nos cabeçalhos Bundle SymbolicName e Require-bundle (por agora).

• O cabeçalho Bundle SymbolicName é usado para gerar uma provide virtual para o rpm do qual o bundle faz parte no formato Provides: osgi (bundle-SymbolicName) = bundle-version. Isso é feito para cada bundle OSGi no RPM, de modo que o número desses provides será o mesmo que o número de feixes nele. Essa geração de provides foi ativada no início da fase de desenvolvimento do Fedora 17 e estará disponível para utilização assim que o Fedora 17 for lançado. “Como isso vai melhorar a vida dos pacotes?”, alguém pode perguntar. – Você sabe qual o package e.g. javax.servlet está presente? Não precisa mais. Colocar Requires: osgi (javax.servlet) no seu arquivo spec é tudo que você precisa. Ou você pode usar o yum para consultar repoquery `- whatprovides osgi (javax.servlet) “.

• Cabeçalhos Require-bundle são usados para a geração automática de requisições, assim as pessoas não acabam com dependências não sendo instaladas. O formato usado é praticamente o mesmo do Requires: osgi (pacote SymbolicName). Poucas coisas precisam ser mencionadas aqui – Requisições opcionais são descartados porque RPM (no Fedora) não tem o conceito de soft-Require e versões não são adicionadas ao Require por um motivo que será explicado mais tarde. O gerador Requires acaba de ser habilitado no Rawhide (futuro Fedora 18) e até agora não está apresentando maiores problemas com um caso muito grande de teste – o SDK Eclipse.

Importar/Exportar pacotes é uma grande parte da especificação OSGi e até mesmo a maneira recomendada para especificar dependências. Aqui vou explicar por que não faz sentido para pacotes RPM sem questionar sua usabilidade geral, simplesmente não se encaixa em nosso fluxo trabalho.

• Ter provides/requires para cada pacote de importação/exportação é muito detalhado e vai poluir tanto os metadados rpm a ponto de prejudicar cada usuário com tempo desnecessário para fazer o download de metadados.
• Não queremos múltiplos Providers para o mesmo pacote – nós queremos um único Provider, estável e bem testado.

Essa diferença é grande o suficiente até mesmo para me fazer pensar no Passo 2 em que cabeçalhos Import-Package são usados em tempo de compilação para mapeá-los para Require-Bundle. Essa não será uma tarefa fácil, mas é possível porque em tempo de compilação sabemos qual bundle exporta o pacote necessário.

Agora não ter versões em requisições. Primeiro de tudo, não existe um mapeamento simples entre intervalos de versão OSGi e RPM. O OSGi recomenda o uso de intervalos de versão, enquanto em RPM é considerada uma prática muito ruim para usar qualquer outra coisa, menos para configurar a menor versão suportada. Segundo, temos, geralmente, apenas um pacote que fornece dado OSGi Bundle. Em terceiro lugar, mais de um OSGi bundles são normalmente agrupados em um único RPM. A combinação de tudo isso faz com que a satisfação do Requires Generated chegue a 90% na maioria dos casos e no resto ainda podemos adicionar as requisições (como fazemos agora).

Isso não é uma solução completa que abrange apenas o caso mais comum, mas ainda vai evitar uma série de problemas como o Eclipse falhando o fornecimento por causa da falta de requisições para algum plugin e etc.

Uma vez que a automação atual faz o seu caminho por meio de todo o trabalho de distribuição, a próxima etapa da pode continuar, porque haveria menos tempo gasto em coisas simples, mas demoradas.

?

Texto original disponível em http://akurtakov.blogspot.com.br/2012/02/rpm-osgi-automation-step-1-completed.html