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

Question

Nous avons intégré un runtime OSGi (Equinox) dans notre application client-serveur personnalisée pour faciliter le développement de plugins et jusqu'à présent, les choses se passent bien.Nous utilisons Eclipse pour créer des plugins grâce à l'éditeur de manifeste intégré, à la gestion des dépendances et à l'assistant d'exportation.Utiliser Eclipse pour gérer les builds n'est pas très propice à une intégration continue via Hudson.

Nous avons des bundles OSGi qui dépendent d’autres bundles OSGi.Je détesterais vraiment coder en dur l'ordre de construction dans une version ANT personnalisée.Nous avons fait cela, c'est du passé et c'est assez horrible.Existe-t-il un outil de build capable de gérer FACILEMENT les dépendances OSGi, voire de les résoudre automatiquement ?Existe-t-il des exemples DÉCENTS de la façon de procéder ?

CLARIFICATION:

Les scripts de build générés ne sont utilisables que via Eclipse.Ils nécessitent l’exécution manuelle de morceaux d’Eclipse.Nous avons également des cibles standard que la version Eclipse n'aura pas, et je ne veux pas modifier le fichier généré car je peux le régénérer (je sais que je peux faire des inclusions, mais je veux éviter tout le fichier de génération Eclipse ensemble)

Voici la présentation de mon projet :

/
-PluginA
-PluginB
-PluginC
.
.
.

En utilisant le PDE Eclipse, chaque plugin a un manifeste, mais pas de build.xml car le PDE le fait pour moi.Difficile d'automatiser un processus piloté par une interface graphique avec Hudson.J'aimerais configurer mon propre build.xml pour construire chacun, MAIS il existe des dépendances et des problèmes d'ordre de construction.Ces problèmes sont dus aux 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 recherche un outil pour aider à automatiser la gestion des dépendances de l'ordre de construction.

Answer 1

Clôture de vieilles questions...

Notre configuration n'était pas propice à Maven en raison du manque de connectivité réseau et de timing.Je sais qu'il existe des configurations Maven hors ligne, mais c'était trop compte tenu du temps.J'espère que nous pourrons 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 de fourmis personnalisées.Les différentes dépendances du bundle sont gérées manuellement.Nous utilisions déjà Ant ;Le BND et les tâches personnalisées ont tout lié.Les tâches personnalisées garantissaient simplement que nos projets bnd/eclipse étaient synchronisés.

Answer 2

Maven2 jusqu'au bout ;a un plugin Eclipse appelé m2éclipse pour aider à le gérer, résout exactement le problème de dépendance et plus encore.A un livre en ligne gratuit comme documentation.

Regardez spécifiquement projets multi-modules pour regrouper de nombreux composants et demander à Maven de déterminer l'ordre de construction et les dépendances.

Il y a aussi chapitre sur l'intégration Eclipse.

Et ce ne sont que Eclipse et Maven, vous obtenez ensuite quelques cadeaux sympas pour OSGi :

• Le Plugin Apache Félix BND Maven générera automatiquement vos manifestes ou à tout le moins vous aidera
• Le Projet PAX OPS4J et leurs plugins Maven peuvent être d'une grande aide pour démarrer des projets, fournir des lanceurs, etc.

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

Answer 3

Secondage de Maven2.Examinez les plugins Tycho pour la construction - ils utilisent le compilateur JDT d'Eclipse afin qu'il implémente toutes les règles OSGi au moment de la compilation, de la même manière qu'Eclipse le fait au moment de l'exécution.

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

Answer 4

Nous utilisons Buckminster.Il s'agit d'un framework de construction et d'assemblage, qui s'occupe de la résolution des dépendances, de la récupération à partir de divers référentiels, de la construction et du packaging du produit.

C'est 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 les résoudre et les construire.Par exemple, feature.xml et l'en-tête Require-Bundle dans Manifest.MF, .product.

Nous n'avons actuellement aucun script de build dans chaque bundle ;nous avons maintenant une seule version par produit.Buckminster prend soin de parcourir le graphique des dépendances.

Il a fallu un peu d'efforts pour faire fonctionner notre système de régulateur de vitesse/fourmi existant, bien qu'ils (l'équipe Buckminster) aient 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 en sommes vraiment impressionnés, même s'il s'agit d'un jeu relativement balbutiant.

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

Nous étudions également actuellement Cadre de test Spring DM pour augmenter l’effort de tests unitaires.

Answer 5

Construction sans tête PDE.C'est bien documenté par Eclipse.Si vous créez des plugins Eclipse et que vous souhaitez le faire via la ligne de commande, la version sans tête Eclipse PDE est LA voie à suivre.

Answer 6

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

Answer 7

Nous utilisons Hudson combiné avec Générateur de plugins pour créer nos bundles/plugins OSGi basés sur Eclipse.Cela s'appuie sur le processus PDE standard d'Eclipse pour la création de plugins.Cela signifie utiliser Eclipse comme compilateur.

Answer 8

Maven ne nécessite pas de connectivité Internet !Utilisez le commutateur -o, pour l'amour de Dieu.

Answer 9

J'utilise maven 3.0.2

mvn générer: archétype

select 252 - osgi-archetype
mvn idea:idea

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

pour ajouter vos dépendances dans le bundle, utilisez ce court exemple dans le pom.xml

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

ou

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