J'ai un projet qui fait référence à un certain nombre de bibliothèques open source, de nouvelles nouvelles, d'autres non si nouvelles. Cela dit, ils sont tous stables et je souhaite coller avec mes versions choisies jusqu'à ce que j'ai eu le temps de migrer vers les versions plus récentes (j'ai testé HSQLDB 2.0 hier et contient de nombreuses modifications de l'API).
L'une des bibliothèques que j'ai souhaité in intégrer est Jasper Rapports, mais comme vous le savez tous sûrement, il est livré avec une montagne de fichiers de jar et je n'ai besoin que d'un sous-ensemble de la montagne (connu), donc je prévois de Postupe personnalisée toutes mes bibliothèques dépendantes.
SO:
Est-ce que tout le monde est personnalisé-fabriquant ses propres faisceaux OSGI pour les bibliothèques open-source qu'ils utilisent ou y a-t-il une source principale de versions OSGI de bibliothèques communes?
En outre, je pensais que ce serait beaucoup plus simple pour chacun de mes faisceaux simplement d'intégrer ses bocaux à charge dans le paquet lui-même. Est-ce possible? Si je choisis d'intégrer les bibliothèques 3ème partie FOC dans un ensemble, je suppose que je devrais produire 2 fichiers JAR, un sans les bibliothèques intégrées (pour que les bibliothèques soient chargées via la classe de classe via Standard Classloader) et une version OSGI comprenant La bibliothèque intégrée devrais donc choisir un nom d'un ensemble comme celui-ci << MyProjectName >> - << Sous-projet >> - Osgi-.1.0.0.jar?
Si je ne peux pas intégrer les bibliothèques open source et choisir de faire personnaliser les bibliothèques open source (via BND), dois-je choisir un nom unique pour éviter tout conflit avec un paquet officiel possible? par exemple. << MyProjectName >> - << 3RDPartylibname >> - << 3rdPartylibversion >>. JAR?
Mon projet activé non OSGI analyse actuellement pour les plugins personnalisés via numériser les dossiers Meta-Inf dans mes différents pots de plugin via Service.Providers (...). Si je vais Osgi, ce mécanisme fonctionnera-t-il toujours?
6 Réponses :
Peut-être que vous recherchez quelque chose comme Maven ? Je ne sais pas comment cela fonctionnerait avec Osgi. Vous pouvez trouver une petite infos sur les rapports Jasper avec Maven ici: http://mvnrepository.com/artifact/jasperreports/jasperReports
Le lien n'est pas pour les paquets OSGI. Mais c'est un joli lien pour voir les dépendances de Jasper.
Je préfère ne pas intégrer les bocaux dépendants (oui c'est possible). Il provoque deux problèmes,
1) Il n'y a pas de réutilisation de ce code. De nombreux faisceaux peuvent simplement faire la même chose (intégrer le même pot) et vous vous retrouvez avec le même pot installé plusieurs fois. Vous pouvez affirmer que votre paquet peut également exporter les interfaces pour le pot incorporé également, mais cela devient laide car il ne faut pas être la responsabilité de votre indication de votre code. Il est également plus facile de disposer de plusieurs versions de la bibliothèque exposée ou de plusieurs fournisseurs de la même version.
2) Ceci est Eclipse spécifique - les bocaux intégrés ne résolvent pas correctement dans l'environnement de développement (fonctionne toujours au moment de l'exécution). Mon ensemble peut dépendre d'un paquet dans ma plate-forme cible, et il ne parviendra pas à résoudre les éléments des pots intégrés, ils doivent être importés dans l'espace de travail pour travailler.
J'ai trouvé que la plupart des pots de source ouverts ont déjà été gentilsement groupé par les gentils personnes au printemps . Il existe également d'autres repos disponibles, mais malheureusement, j'ai perdu mes liens avec eux.
Les pots de printemps ont imprimé le printemps sur eux et ils semblent être des versions plus anciennes de bibliothèques (telles que la version 2.0.5 des rapports Jasper). Osgi semble sympathique en théorie, mais il semble que tout le monde construit leurs propres faisceaux (printemps inclus), ce qui défait le but. Sans parler du problème JDBC avec OSGI. DLL L'enfer a été résolu avec la classe de classe. L'enfer de classe a été résolu avec Osgi. Qu'est-ce qui va nous sauver d'Osgi Bundle Hell?
@Chris - assez vrai sur la nommée, mais puisqu'il n'y a pas d'autorité centrale pour fournir aux paquets et qu'ils ne sont pas créés par le propriétaire, cela ressemble à un compromis raisonnable. Au moins, vous savez d'où cela vient, et cela ne fait aucune différence une fois déployée. En ce qui concerne son utilité, il s'agit simplement d'un autre outil à la ceinture, très utile pour la construction de systèmes de type enfichable.
L'idée d'utiliser le ressort repo comme source de plugins RCP externes est excellente mais où puis-je trouver l'URL du site Repo / Mettre à jour que je dois ajouter à ma définition cible. J'ai essayé de google mais n'a pas été capable de trouver une URL de travail. Je sais que l'ajout de l'URL à la réponse s'épuisera bientôt. Mais cela aiderait définitivement et peut-être que d'autres vont le mettre à jour dans le futur ...
Le projet d'orbite Eclipse a également fait des paquets de nombreux bocaux tiers couramment utilisés.
Merci pour le lien. Malheureusement, ma question reste cependant.
Pour être précis sur les questions que vous avez posées.
Tout le monde ne fait pas leur propre. Consultez ma réponse précédente pour un lien vers l'emballage Eclipse des bibliothèques tiers en tant que paquets. Si vous ne trouvez pas et que vous ne trouvez pas la version déjà emballée, vous devrez faire la vôtre.
Il vaut mieux envelopper des dépendances binaires dans leur propre paquet que d'inclure le bocal en tant que binaire dans votre paquet de code. Choisissez le nom de l'ensemble que vous souhaitez, ses importations et exportations de paquet qui comptent. Nomspacing Le nom du paquet avec votre nom de projet garantira de ne pas frapper les collisions.
Accéder à l'accès à la zone de stockage du paquet pour la numérisation n'est pas impossible, mais il a tendance à exiger des informations spécifiques à l'exécution d'OSGI sur la manière / où les paquets sont extraits. Donc, c'est possible, mais pas facile.
Via Osgi, comment savoir quels plugins sont disponibles via des paquets non installés? Je numérise habituellement la classe de classe pour un fichier que j'ai mis dans le méta-inf. Il semble en quelque sorte que Osgi est incompatible avec tout ce qui utilise actuellement la classe de classe pour la modularité. "Mon projet activé non-OSGI analyse actuellement pour les plugins personnalisés via numériser les dossiers Meta-Inf dans mes différents pots de plug-in via Service.Providers (...). Si je vais Osgi, ce mécanisme fonctionnera-t-il toujours?"
Spring a créé des ensembles OSGI de la plupart des bibliothèques open source et je vois des rapports Jasper. Découvrez leur référentiel de paquets @ http://www.springsource.com/repository/app/bundle < / a>
Nous utilisons Maven avec OSGI, nous déclarons les dépendances de la paquet dans son pom.xml et vous ne pas avoir à m'en soucier d'eux plus.
Ce n'est pas entièrement vrai, cependant. Vous devez obtenir ou créer les paquets vous-même (tout n'est pas fourni), vous devez laisser les paquets être déployés et gérer le bon versement (vous ne pouvez pas simplement remplacer un paquet avec une version plus élevée, une version plus élevée pourrait avoir besoin de la version plus ancienne. ) etc. Ceci est particulièrement important si le déploiement est traité par une division différente de la société - les administrateurs système par exemple.