Dois-je utiliser les plug-ins Eclipse (ou Bundles OSGi) en tant qu'outil de gestion des dépendances?

Question

encore une fois c'est arrivé ... J'ai rejoint un nouveau projet, composé de plusieurs projets Java Eclipse simples, avec des interdépendances, tous gérés via le chemin de construction du projet. Je trouve tout cela un peu chaotique. Et quand il s'agit d'exécuter des configurations - vous venez d'entrer en enfer.

Dans le passé, je me suis contenté de créer des projets plug-in, au lieu de projets Java simples - même si je n'ai jamais l'intention d'exécuter ces projets en tant que osgi-bundles. Je trouve simplement que les dépendances sont beaucoup plus faciles à gérer dans les projets plug-in. Les autres personnes prennent-elles le même chemin? Quelque chose contre cette approche?

Answer 1

Si vous lisez le restructure of org.aspectj document, ce projet a précisément:

• Toutes les dépendances seraient exprimées dans OSGi bundle fichiers manifestes, qui spécifient un classpath (pour les pots de bibliothèque) et des faisceaux « nécessaires » .
  Les bibliothèques attendues ou espérées dans l'environnement de déploiement (par exemple, XML ou JRocket) doivent être incluses à des fins de construction et de test, mais exclues du produit d'expédition. Ceux-ci peuvent être spécifiés comme paquets obligatoires "facultatifs" ou comme requis-packages

• L'assemblage binaire initial fonctionnerait par le biais de l'assemblage de bundle habituel, avec la sortie du bundle incluant les binaires des fragments de bundle requis (mais pas des bundles optionnels)

les avantages comprennent également la la version aspect de OSGi, qui permet de spécifier la version attendue minimum et maximum d'une dépendance.

Answer 2

Cela semble une approche intéressante, mais personnellement, je pense qu'il est préférable de gérer les dépendances de construction en utilisant un outil de construction externe comme Ant ou Maven plutôt que d'attacher votre build à un IDE. Si vous utilisez maven et le plugin m2eclipse, il configurera automatiquement les dépendances du projet Eclipse lors du chargement du Maven POM si ces autres projets se trouvent également dans votre espace de travail. Malheureusement, si votre équipe utilise actuellement la gestion des dépendances ad-hoc, il est peu probable qu'ils veuillent faire l'effort de passer directement à Maven. Là encore, peut-être qu'ils ont juste besoin d'un leader pour mener l'effort.

Answer 3

Je n'utiliserais pas de projets plug-in personnellement, j'utiliserais des outils de construction tels que Ant, Maven et autres.

S'il n'y a pas de système de construction intégré, cela signifie que l'entreprise ne comprend pas grand chose sur le développement logiciel.

Je ne prendrais pas toute la responsabilité d'introduire un système de construction, peut-être des heures supplémentaires. S'ils ne veulent pas migrer, je suggère que vous commenciez à chercher un autre emploi dès que possible.

Answer 4

Je pense que votre méthodologie, pour utiliser OSGi pour la gestion des dépendances même si vous ne courez pas dans un conteneur OSGi, est très bonne car elle aboutira finalement à un code plus modulaire. Le code modulaire est plus facile à refactoriser et plus facile à distribuer entre plusieurs développeurs. Vous n'avez même pas besoin d'étendre les classes OSGi, vous ne créez donc aucune dépendance supplémentaire. D'autre part, la suggestion de Ken Liu d'utiliser une gestion des dépendances externes a aussi ses avantages, puisque quelque chose comme Maven va gérer beaucoup de dépendances et de gestion pour vous.Combinez les deux et obtenez le meilleur des deux mondes. OSGi peut être conçu pour fonctionner avec Maven en utilisant des bibliothèques supplémentaires telles que Bnd et m2eclipse.

Answer 5

Il y a deux problèmes distincts ici.

1. Comment puis-je mis en place plusieurs projets et
2. qui tirent parti de système me permet de construire plusieurs projets

Les deux n'a pas besoin d'être liés. Ainsi, par exemple, vous pouvez choisir Maven pour construire les projets mais utiliser des projets de plugins pour faciliter les modifications. La plupart des choses ont battu le système de construction Eclipse; Une fois que cela fonctionne, c'est assez stable - mais le faire passer de rien au travail implique (a) de la chance, et/ou (b) de la magie noire. En fin de compte, la question se résume à laquelle vous vous sentez plus facile à gérer; les deux types de dépendance, ou juste un seul. Si vous en voulez un seul, vous devez investir le temps dans quelque chose comme m2eclipse (qui génère des dépendances de projet à partir du POM maven) ou en utilisant pax-construct (qui peut générer le manifeste à partir du POM maven). Soit ça, ou vivre avec deux systèmes de gestion de dépendance.

Answer 6

Je suis d'accord que dans Eclipse, il est plus facile de gérer les dépendances de projet en utilisant OSGi que la manière traditionnelle d'ajouter des références de projet ou de bibliothèque. Cependant, si vous faites la promotion de la gestion des dépendances OSGi au moment du développement, les développeurs devront apprendre OSGi et cela entraînera des coûts en raison des problèmes de visibilité des classes. Utilisez-vous Require-Bundle ou Import-Package pour gérer les dépendances? Même si Require-Bundle n'est pas le choix recommandé avec OSGi, il pourrait être mieux adapté du point de vue de la gestion des dépendances au moment du développement. A moins d'utiliser quelque chose comme le plug-in Maven, Eclipse a la fâcheuse division de méthodes de compilation/exécution complètement différentes à l'intérieur et à l'extérieur d'Eclipse - avec la peine de maintenir 2 systèmes parallèles de compilation/exécution.