How to link OSGI bundles on eclipse?

Viewed 347

I am using serviceMix to deploy my bundles. Whereas I am using maven to create my bundles as follow:

        <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 Import a class from one of my others bundle as follow:

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

But when I try to access it inside my current Bundle, it gives me error that no such class is there.
I am using eclipse and maven to create bundles and deploy them on serviceMix.
Here is the Image of the pom project where I am trying to use that bundle.

enter image description here

And below is the image of the bundle which I created and want to use its imported package.

enter image description here

1 Answers

The configuration that you provided for the maven bundle plugin is rather unusual, and probably doesn't match what you actually want.

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

These two entries are fine, although I believe that ${project.groupId}.${project.artifactId} is the default for a bundle's symbolic name when using the maven bundle plugin, and so it could be omitted

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

Using a BundleActivator is not typically recommended as it's an extremely low-level entry point. There are lots of sharp edges and it's easy to get things badly wrong. Typically you would be recommended to use a component framework such as Declarative Services, which does most of the hard work for you. This is the correct way to declare your activator class, but other readers beware.

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

This is a badly written Import-Package instruction. In general you should not specify this header at all and the plugin will calculate the correct list for you. If you do specify this header then it is advanced usage and you have to be careful.

Firstly this header is wrong because the tokens are taken as a list of filters and interpreted in turn. By starting with * the rest of the header is irrelevant.

Secondly this header must be a list of packages (or glob matches/negations) and must not contain class names. If mycom.project.ManageSQL.Interface.SQLInterface is not a class name then it seriously violates the Java naming conventions.

I would recommend that you delete your Import-Package configuration entry completely.

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

As with the Import-Package instruction, Export-Package must take a package name, not a class name.

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

This Private-Package instruction (combined with the Export-Package instruction) is responsible for deciding which classes will end up packaged into your bundle. It is unusual (although not unheard of) to repackage dependencies from another bundle into your own bundle. This is a bit like static linking in a native executable, however you need to be very careful to avoid repackaging things which are exposed through your API to avoid serious problems at runtime.

Private-Package and Export-Package can only include packages which are on the compilation classpath. At a guess this is why your bundle doesn't contain the things that you expect, although I would question why you are repackaging these packages in the first place.

<BundleType>project</BundleType>

This is a custom header in a global namespace. I would recommend using something more recognisably unique to your company, or removing the header if it doesn't serve a practical purpose.

Related