Como posso gerenciar dependências de compilação do OSGi?

Question

Incorporamos um tempo de execução OSGi (Equinox) em nosso aplicativo cliente-servidor personalizado para facilitar o desenvolvimento de plug-ins e até agora as coisas estão indo muito bem.Temos usado o Eclipse para construir plug-ins devido ao editor de manifesto integrado, gerenciamento de dependências e assistente de exportação.Usar o Eclipse para gerenciar compilações não é muito propício à integração contínua via Hudson.

Temos pacotes OSGi que dependem de outros pacotes OSGi.Eu realmente odiaria codificar a ordem de compilação em uma compilação ANT personalizada.Já fizemos isso é passado e é horrível.Existe alguma ferramenta de construção que possa gerenciar FACILMENTE as dependências do OSGi, se não as resolver automaticamente?Existem exemplos DECENTES de como fazer isso?

ESCLARECIMENTO:

Os scripts de construção gerados só podem ser usados ​​via Eclipse.Eles exigem a execução manual de partes do Eclipse.Também temos alguns alvos padrão que a compilação do Eclipse não terá, e não quero modificar o arquivo gerado, pois posso regenerar (sei que posso incluir, mas quero evitar o arquivo gen do Eclipse todos junto)

Aqui está o layout do meu projeto:

/
-PluginA
-PluginB
-PluginC
.
.
.

Ao usar o Eclipse PDE, cada plugin possui um Manifesto, mas nenhum build.xml, pois o PDE faz isso por mim.Difícil automatizar um processo orientado por GUI com Hudson.Gostaria de configurar meu próprio build.xml para construir cada um, MAS há dependências e problemas de ordem de construção.Esses problemas são causados ​​pelos arquivos de manifesto (que descrevem as importações do OSGi).Por exemplo, PluginC depende do PluginB que depende do PluginA.Eles devem ser construídos na ordem correta.Sei que posso controlar manualmente a ordem de construção. Estou procurando uma ferramenta para ajudar a automatizar o gerenciamento de dependências da ordem de construção.

Answer 1

Fechando algumas perguntas antigas...

Nossa configuração não foi propícia ao maven devido à falta de conectividade de rede e tempo.Eu sei que existem configurações maven offline, mas foi demais, dado o tempo.Esperamos que possamos usar uma configuração adequada quando tivermos tempo para reorganizar o processo de construção.

A solução envolveu Ant, BND e algumas tarefas personalizadas do Ant.As diversas dependências do pacote configurável são gerenciadas manualmente.Já estávamos usando Ant;O BND e as tarefas personalizadas uniram tudo.As tarefas personalizadas apenas garantiram que nossos projetos bnd/eclipse estivessem sincronizados.

Answer 2

Maven2 até o fim;tem um plugin Eclipse chamado m2Eclipse para ajudar no gerenciamento, resolve exatamente o problema de dependência e muito mais.Tem um livro online gratuito como documentação.

Olhe especificamente para projetos multimódulos para agrupar muitos componentes e fazer com que o Maven resolva a ordem de construção e as dependências.

Há também um capítulo sobre a integração do Eclipse.

E isso é apenas Eclipse e Maven, a seguir você ganha algumas novidades legais para OSGi:

• O Plug-in Apache Felix BND Maven irá gerar automaticamente seus manifestos ou pelo menos ajudá-lo
• O Projeto PAX OPS4J e seus plug-ins Maven podem ser uma grande ajuda na inicialização de projetos, no fornecimento de inicializadores, etc.

E fundamentalmente, o modelo de módulo Maven se encaixa perfeitamente no modelo de pacote OSGi.Temos construído e gerenciado vários produtos com centenas de pacotes usando o Maven há mais de 3 anos e isso é ótimo.

Answer 3

Destacando Maven2.Procure nos plug-ins Tycho para construção - eles usam o compilador JDT do Eclipse para implementar todas as regras OSGi em tempo de compilação, da mesma forma que o Eclipse faz em tempo de execução.

Alternativamente, os plugins Apache Felix BND também parecem populares.Eu prefiro Tycho porque parece unificar mais os ambientes de desenvolvimento Maven e Eclipse.

Answer 4

Nós usamos Buckminster.É um framework de construção e montagem, que cuida da resolução de dependências, da busca em diversos repositórios, da construção e do empacotamento do produto.

É um projeto do Eclipse Tools.Ele se integra bem com PDE.

Isso significa que todos os metadados que usamos para construir o RCP são úteis para Buckminster resolver e construir.Por exemplo, feature.xml e o cabeçalho Require-Bundle no Manifest.MF, .product.

Não temos nenhum script de construção em cada pacote agora;agora temos uma única compilação por produto.Buckminster toma cuidado ao percorrer o gráfico de dependência.

Foi necessário um pouco de esforço para fazer com que nosso sistema existente de controle de cruzeiro/formiga funcionasse com ele, embora eles (a equipe de Buckminster) tenham começado a usar o Hudson para hospedar o projeto em si.Acredito que a configuração de compilação deles também esteja disponível para download.

Estamos realmente impressionados com isso, apesar de ser relativamente infantil.

Também examinamos Pax-Construir mas não queríamos usar o Maven.

Também estamos analisando Estrutura de teste Spring DM para aumentar o esforço de teste de unidade.

Answer 5

Construção PDE sem cabeça.Está bem documentado pelo Eclipse.Se você estiver construindo plug-ins do Eclipse e quiser fazê-lo por meio da linha de comando, a construção sem cabeça do Eclipse PDE é o caminho a seguir.

Answer 6

Você pode explicar onde o problema ocorre?Você menciona dependências do pacote OSGi.Isso ocorre durante o tempo de execução?Ou durante o tempo de compilação?No primeiro caso, você deve considerar os Serviços Declarativos (consulte as especificações OSGi).

Answer 7

Usamos Hudson combinado com PluginBuilder para construir nossos pacotes/plugins OSGi baseados em Eclipse.Isso se baseia no processo PDE padrão do Eclipse para construção de plug-ins.Isso significa usar o Eclipse como compilador.

Answer 8

Maven não requer conectividade com a Internet!Use a opção -o, pelo amor de Deus.

Answer 9

Eu uso o maven 3.0.2

mvn gerar: arquétipo

select 252 - osgi-archetype
mvn idea:idea

ver http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

para adicionar suas dependências ao pacote, use este pequeno exemplo no pom.xml

<Export-Package>org.foo.myproject.api</Export-Package>

ou

<Import-Package>org.foo.myproject.api</Import-Package>