Comment puis-je gérer les dépendances de construction OSGi?

Question

Nous avons intégré un environnement d'exécution OSGi (Equinox) dans une application client-serveur personnalisée pour faciliter le développement de plug-ins et, jusqu'à présent, tout va bien. Nous avons utilisé Eclipse pour créer des plugins en raison de l'éditeur de manifeste intégré, de la gestion des dépendances et de l'assistant d'exportation. L'utilisation d'Eclipse pour créer des gestionnaires n'est pas très propice à une intégration continue via Hudson.

Nous avons des groupes OSGi qui dépendent d'autres groupes OSGi. Je déteste vraiment coder l'ordre de construction dans une construction ANT personnalisée. Nous avons fait ceci est le passé et c'est assez horrible. Existe-t-il un outil de construction qui peut FACILEMENT gérer les dépendances OSGi, sinon les résoudre automatiquement? Y a-t-il des exemples décents de comment cela?

CLARIFICATION:

Le produit de créer des scripts ne sont utilisables que par Eclipse. Ils nécessitent d'exécuter manuellement des morceaux d'Eclipse. Nous avons aussi des cibles standards que la construction Eclipse n'aura pas, et je ne veux pas modifier le fichier généré car je peux régénérer (je sais que je peux faire inclut, mais je veux éviter le fichier gen Eclipse ensemble)

Voici ma mise en page du projet:

/ 
-PluginA 
-PluginB 
-PluginC 
. 
. 
. 

en utilisant l'Eclipse PDE, chaque plugin a un Manifest, mais pas build.xml comme le fait pour PDE moi. Difficile d'automatiser un processus piloté par gui avec Hudson. Je voudrais configurer mon propre build.xml pour construire chacun, MAIS il y a des dépendances et des problèmes d'ordre de construction. Ces problèmes sont provoqués par les fichiers Manifest (qui décrivent les importations OSGi). Par exemple, PluginC dépend de PluginB qui dépend de PluginA. Ils doivent être construits dans le bon ordre. Je me rends compte que je peux contrôler manuellement l'ordre de construction, je cherche un outil pour aider à automatiser la gestion de dépendance de commande de construction.

Answer 1

clôture quelques vieilles questions ...

Notre configuration n'a pas été propice à maven en raison du manque de connectivité réseau et le calendrier. Je sais qu'il y a des configurations de maven hors ligne, mais c'était trop donné étant donné le temps. Nous espérons pouvoir utiliser une configuration appropriée lorsque nous aurons le temps de réorganiser le processus de construction.

La solution impliquait Ant, BND et certaines tâches ant personnalisées. Les différentes dépendances de bundle sont gérées manuellement. Nous utilisions déjà Ant; BND et les tâches personnalisées liés tout ensemble. Les tâches personnalisées ont juste veillé à ce que nos projets bnd/eclipse soient synchronisés.

Answer 2

Nous utilisons Buckminster. C'est un framework de construction et d'assemblage, qui s'occupe de la résolution des dépendances, de la récupération de différents référentiels, de la construction et du packaging du produit.

Il s'agit d'un projet Eclipse Tools. Il s'intègre bien avec PDE.

Cela signifie que toutes les métadonnées que nous utilisons pour construire le RCP sont utiles à Buckminster pour résoudre et construire. Par exemple, feature.xml et l'en-tête Require-Bundle dans le fichier Manifest.MF, .product.

Nous n'avons pas de scripts de construction dans chaque bundle maintenant; nous avons maintenant une seule construction par produit. Buckminster prend soin de marcher le graphique de dépendance.

Il a fallu un peu d'effort pour faire fonctionner notre système de contrôle de croisière/fourmis existant, même si (l'équipe de Buckminster) a commencé à utiliser Hudson pour héberger le projet lui-même. Je crois que leur configuration de construction est également disponible en téléchargement.

Nous sommes vraiment impressionnés par cela, malgré sa petite enfance.

Nous avons également examiné Pax-Construct mais nous ne voulions pas utiliser Maven.

Nous sommes également en train de regarder Spring DM testing framework pour augmenter l'effort de tests unitaires.

Answer 3

Maven2 tout le chemin; a un plugin Eclipse appelé m2eclipse pour aider à la gérer, résout exactement le problème de dépendance, puis certains. Formé d'un free online book as documentation.

Examinez spécifiquement multi-module projects pour regrouper de nombreux composants ensemble et demandez à Maven de définir l'ordre de construction et les dépendances.

Il existe également un chapter on the Eclipse integration.

Et qui est Eclipse juste et Maven, à côté, vous obtenez quelques goodies sympas pour OSGi:

• Le Apache Felix BND Maven plugin va générer automatiquement vos manifestes ou à tout le moins vous aider
• Le PAX OPS4J project et leur Maven les plugins peuvent être d'une grande aide pour démarrer des projets, fournir des lanceurs, etc.

Et tout simplement, le modèle de module Maven s'intègre parfaitement au modèle de bundle d'OSGi. Nous construisons et gérons plusieurs produits avec des centaines de paquets en utilisant Maven depuis plus de 3 ans maintenant et c'est génial.

Answer 4

Pouvez-vous préciser où le problème se produit? Vous mentionnez les dépendances de bundle OSGi. Est-ce pendant l'exécution? Ou pendant la compilation? Dans le premier cas, vous devriez considérer les services déclaratifs (voir OSGi Spec).

Answer 5

Nous utilisons Hudson combiné avec PluginBuilder pour construire nos bundles/plugins OSGi basés sur Eclipse. Cela s'appuie sur le processus PDE standard d'Eclipse pour créer des plugins. Cela signifie utiliser Eclipse comme compilateur.

Answer 6

En second lieu Maven2. Regardez dans les plugins Tycho pour la construction - ils utilisent le compilateur JDT d'Eclipse afin qu'il implémente toutes les règles OSGi à la compilation, comme Eclipse le fait à l'exécution.

Alternativement, les plugins Apache Felix BND semblent également populaires. Je préfère Tycho parce qu'il semble plus étroitement unifier les environnements de développement Maven et Eclipse.

Answer 7

PDE Construire sans tête. C'est bien documenté par Eclipse. Si vous construisez des plugins Eclipse, et que vous voulez le faire via une ligne de commande, la version sans tête Eclipse PDE est LE chemin à parcourir.

Answer 8

Je Maven 3.0.2

mvn generate: archétype

select 252 - osgi-archetype 
mvn idea:idea 

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

ajouter vos dépendances dans l'utilisation du faisceau ce court exemple dans le pom.xml

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

ou

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

Answer 9

Maven ne nécessite pas de connexion Internet! Utilisez l'option -o, pour l'amour du Christ.