2017-10-05 5 views
2

J'utilise serviceMix pour déployer mes bundles. Alors que je me sers Maven pour créer mes paquets comme suit:Comment lier des bundles OSGI sur eclipse?

 <plugin> 
      <groupId>org.apache.felix</groupId> 
      <artifactId>maven-bundle-plugin</artifactId> 
      <version>2.3.6</version> 
      <extensions>true</extensions> 
      <configuration> 
       <instructions> 
        <Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName> 
        <Bundle-Description>${project.description}</Bundle-Description> 
        <Bundle-Activator>mycom.project.PubSub.activator.Activator</Bundle-Activator> 
        <Import-Package>*,org.apache.camel.osgi,org.java_websocket.*, mycom.project.ManageSQL.Interface.SQLInterface 
        </Import-Package> 
        <Export-Package>mycom.project.PubSub.Manager.Manager</Export-Package> 
        <Private-Package>org.java_websocket.*, mycom.project.PubSub.*, io.socket.*, okhttp3.*, okhttp3.internal.connection, okio.*, org.json.*</Private-Package> 
        <BundleType>project</BundleType> 
       </instructions> 
      </configuration> 
     </plugin> 

I Importer une classe d'un de mes autres paquet comme suit:

<Import-Package>*,org.apache.camel.osgi,org.java_websocket.*, mycom.project.ManageSQL.Interface.SQLInterface</Import-Package> 

Mais quand je tente d'accéder à l'intérieur de mon paquet en cours , cela me donne l'erreur que ce genre de classe n'existe pas.
J'utilise eclipse et maven pour créer des bundles et les déployer sur serviceMix.
Voici l'image du projet pom où j'essaye d'utiliser ce paquet.

enter image description here

Et ci-dessous est l'image du paquet que j'ai créé et que vous souhaitez utiliser son emballage importé.

enter image description here

Répondre

0

La configuration que vous avez fourni pour le plug-in bundle Maven est plutôt inhabituel, et ne correspond probablement pas ce que vous voulez vraiment.

<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName> 
<Bundle-Description>${project.description}</Bundle-Description> 

Ces deux entrées sont très bien, même si je crois que ${project.groupId}.${project.artifactId} est la valeur par défaut pour le nom symbolique d'un paquet lors de l'utilisation du plug-in bundle Maven, et il pourrait donc être omis

<Bundle-Activator>mycom.project.PubSub.activator.Activator</Bundle-Activator> 

L'utilisation d'un BundleActivator est n'est généralement pas recommandé car il s'agit d'un point d'entrée de très bas niveau. Il y a beaucoup d'arêtes vives et il est facile de mal faire les choses. Généralement, il vous est recommandé d'utiliser un framework de composants tel que Declarative Services, qui effectue le plus gros du travail pour vous. C'est la bonne façon de déclarer votre classe d'activateur, mais attention aux autres lecteurs. Il s'agit d'une instruction Import-Package mal écrite. En général, vous ne devez pas spécifier cet en-tête et le plugin va calculer la bonne liste pour vous. Si vous spécifiez cet en-tête, il s'agit d'une utilisation avancée et vous devez faire attention.

Tout d'abord, cet en-tête est erroné car les jetons sont considérés comme une liste de filtres et interprétés à tour de rôle. En commençant par *, le reste de l'en-tête n'est pas pertinent.

D'autre part, cet en-tête doit être une liste de paquets (ou glob correspond/negations) et ne doit pas contenir de noms de classe. Si mycom.project.ManageSQL.Interface.SQLInterface n'est pas un nom de classe, cela viole gravement les conventions de dénomination Java.

Je vous recommande de supprimer complètement votre entrée de configuration Import-Package.

<Export-Package>mycom.project.PubSub.Manager.Manager</Export-Package> 

Comme l'instruction Import-Package, Export-Package doit prendre un nom de paquet, pas un nom de classe.

<Private-Package>org.java_websocket.*, mycom.project.PubSub.*, io.socket.*, okhttp3.*, okhttp3.internal.connection, okio.*, org.json.*</Private-Package> 

Cette instruction Private-Package (combinée à l'instruction Export-Package) est chargé de décider quelles classes finiront emballés dans votre paquet. Il est inhabituel (mais pas inconnu) de reconditionner les dépendances d'un autre bundle dans votre propre bundle. C'est un peu comme une liaison statique dans un exécutable natif, mais vous devez être très prudent pour éviter de reconditionner les éléments qui sont exposés via votre API pour éviter de graves problèmes lors de l'exécution.

Private-Package et Export-Packagepeuvent uniquement inclure des packages qui se trouvent sur le chemin de classe de compilation. Au hasard, c'est pourquoi votre bundle ne contient pas les choses que vous attendez, bien que je vous demanderais pourquoi vous remballez ces paquets en premier lieu.

<BundleType>project</BundleType> 

Ceci est un en-tête personnalisé dans un espace de noms global. Je recommande d'utiliser quelque chose de plus reconnaissable unique à votre entreprise, ou en supprimant l'en-tête si elle ne sert pas un objectif pratique.