Gestion des regroupements d'équipes

Question

Nous transférons notre application vers la plateforme OSGI (tous les développeurs utilisent Eclipse) et nous essayons de trouver le meilleur environnement d'équipe pour développer nos bundles.

Nous avons des offres groupées provenant de plusieurs sources :

1. Les paquets communs de projets tels qu'Orbit ou Apache qui sont gérés par des organismes extérieurs.
2. Des paquets qui enveloppent des fichiers jar spécifiques à un domaine. Nous gérons ces bundles en interne.
3. Les paquets fournis par d'autres équipes de l'entreprise qui sont effectivement en lecture seule pour nous.
4. Paquets fournis par notre équipe qui contiennent un code source activement développé.

Dans les cas 1 à 3, nous voudrions installer dans notre IDE Eclipse local et fournir une plateforme cible. Il me semble que nous devrions simplement créer un dépôt p2 qui fournit tous les bundles dans 1-3 et les fournir comme une définition de cible. N'hésitez pas à nous indiquer une meilleure solution si vous en avez une.

Les paquets contenus dans le cas 4 sont stockés dans un dépôt Mercurial. Bien que la définition de la cible semble pouvoir récupérer des paquets à partir de plusieurs sources, elle n'indique pas comment inclure des paquets à partir d'un (d)vcs.

Quelle est la meilleure pratique ? Devons-nous mettre nos informations sur les bundles (d)vcs dans la plate-forme cible et faire en sorte que les développeurs téléchargent manuellement les bons bundles ? Comment gérer les modifications de la définition de la cible ? Devons-nous envoyer un e-mail à tout le monde lorsqu'il y a un changement, ou existe-t-il une solution plus élégante ?

Merci pour votre aide.

Answer 1

Espace pour partager la cible avec le développeur. L'inconvénient est que nous avons des artefacts dans notre SVN ! Mais le dépôt p2 semble bien meilleur. Lorsque chaque développeur activera la mise à jour automatique, il sera informé lorsque les mises à jour seront disponibles. Je pense que nous devons l'essayer à l'avenir dans mon entreprise.

Le code source que nous avons développé activement est partagé par Ensembles de projets d'équipe (*.psf). Il s'agit d'un fichier texte unique qui contient toutes les informations de dépôt des projets eclipse d'exportet. Essayez-le dans votre IDE Eclipse avec File -> Export -> Team -> Team Project Set . S'il y a des changements sur le Project Set, nous envoyons un email à nos développeurs. Une façon plus élégante, je pense, est de le partager sur le dépôt p2.

J'espère que cela vous aidera et désolé pour mon mauvais anglais !

Answer 2

J'utilise eclipse, m2eclipse, maven-bundle-plugin , subversion, nexus y hudson et cela fonctionne à merveille, surtout dans un environnement d'équipe.

L'automatisation de la génération du manifest.mf est essentielle dans OSGi, car le faire à la main est très sujet aux erreurs. Utilisez bnd pour cela (automatisé par bndtools ou maven-bundle-plugin)

Pax Construct peut aider à construire un environnement d'exécution OSGi complet.

Answer 3

Il est préférable d'utiliser Apache Maven [1] si vous souhaitez utiliser un environnement indépendant d'Eclipse.

Pour :

• tous vos artefacts seront stockés dans un repo Maven. Vous pouvez utiliser des outils tels qu'Artifactory [2] pour créer et partager un repo Maven pour toute l'équipe (afin d'éviter tout problème avec des artefacts tiers).
• il existe de nombreux tutoriels OSGi Maven qui vous aideront à trouver des réponses à presque toutes vos questions.
• Eclipse supporte très bien Maven avec le plugin m2Eclipse [3].
• L'IDE n'est pas si important dans ce cas. Les membres de votre équipe peuvent choisir n'importe quel (même vi ou emacs)

Cons :

• vous devez trouver des dépôts Maven pour tous vos artefacts. Ce n'est pas si facile pour les artefacts Eclipse, mais vous pouvez essayer de les trouver ici : [4]
• modifier la structure de votre projet en fonction des exigences de Maven
• passer du temps à comprendre et à utiliser les patterns Maven (pour OSGi)

[1] - http://maven.apache.org/

[2] - http://www.jfrog.org/products.php

[3] - http://m2eclipse.sonatype.org/

[4] - http://build.eclipse.org/helios/hybrid/final/

Regards, Dmytro

Answer 4

Merci à tous ceux qui ont répondu et qui nous ont permis de savoir comment les autres résolvent ce problème.

Nous avons fini par choisir Buckminster . Il nous permet de décrire rapidement où se trouvent tous nos bundles (cas 1-3 à partir des dépôts p2, cas 4 à partir de mercurial) et permet de configurer en un clic des espaces de travail vides grâce au CQuery. Il s'intègre également bien avec Hudson et simplifie la configuration du CI par rapport au build PDE que j'ai utilisé sur d'autres projets.