Como posso gerenciar dependências de compilação do OSGi?
-
09-06-2019 - |
Pergunta
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.
Solução 4
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.
Outras dicas
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.
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.
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.
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.
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).
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.
Maven não requer conectividade com a Internet!Use a opção -o, pelo amor de Deus.
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>