La structure du paquet de OSGi paquet

Question

J'ai réfléchi un peu sur les « bonnes pratiques » en ce qui concerne la structure de l'emballage dans les bundles OSGi. À l'heure actuelle, en moyenne, nous avons comme 8-12 classes par paquet. Une de mes initiative / proposition a été d'avoir deux paquets; com.company_name.osgi.services.api (pour les classes associées api-/ interfaces (qui est exportée à l'extérieur) et un paquet com.company_name.osgi.services.impl pour la mise en oeuvre (non exportée)). Quels sont les inconvénients pros de cela? Toutes les autres suggestions?

Answer 1

Vous pouvez également envisager puting les interfaces com.company_name.subsystem, et la mise en œuvre com.company_name.subsystem.impl, le code spécifique OSGI, s'il y en a, pourrait être en com.company_name.subsystem.osgi. Parfois, vous pourriez avoir plusieurs application des mêmes interfaces. Dans ce cas, vous pourriez envisager - com.company_name.subsystem.impl1 et com.company_name.subsystem.impl2, par exemple:

com.company.scm        // the scm api
com.company.scm.git    // its git implementaton
com.company.scm.svn    // its subversion implementation
com.company.scm.osgi   // the place to put an OSGI Activator

Dans cette structure de package de sens pourrait être agnostique OSGi, si vous plus tard passer à un autre conteneur, vous mettez juste un supplémentaire

com.company.scm.sca     // or whatever component model you might think of

Toujours avoir api et impl dans votre nom de package pourrait être gênant. En cas de doute l'utilisation impl mais pas api.

Answer 2

Il est pas le nombre de classes qui est importante, mais les concepts. À mon avis, vous devriez avoir une entité conceptuelle dans un paquet. Dans certains cas, cela pourrait être juste quelques cours dans d'autres plusieurs paquets avec 100s de classes.

Qu'est-ce qu'il est important est que vous séparer l'API et la mise en œuvre. Un paquet contient l'API de votre concept et l'autre la mise en œuvre. Comme cela, vous pouvez fournir différentes implémentations pour une API bien définie. Dans certains cas, cela pourrait être encore nécessaire si vous voulez accéder aux services d'un faisceau à distance (en utilisant par exemple R-OGSI)

Les faisceaux API sont ensuite utilisés par le partage de code et les services des faisceaux de mise en œuvre par le partage des services. La meilleure façon d'explorer ces possibilités est de regarder les ServiceTrackers.

Answer 3

Dans votre cas, vous pourriez avoir la mise en œuvre dans le même paquet, mais toutes ses classes « paquet protégé ». De cette façon, vous pouvez exporter le paquet et la mise en œuvre ne serait pas visible à l'extérieur, même lorsqu'ils ne sont pas en utilisant OSGi (mais comme un fichier jar régulier).