can't use bndtools plugin to run a simple osgi application

Question

I am trying to run a simple app using the procedure outlined in this tutorial: BndTools tutorial project.

And this is the osgi project/module I am trying to load.

package com.counter;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.BundleEvent;
import org.osgi.framework.BundleListener;

public class BundleCounterActivator implements BundleActivator,
    BundleListener{

    private BundleContext context;

    public void start(BundleContext context) throws Exception{
        this.context=context;

        context.addBundleListener(this);
        printBundleCount();
    }

    public void stop(BundleContext context)throws Exception{
        context.removeBundleListener(this);
    }

    public void bundleChanged(BundleEvent event){

        switch(event.getType()){

        case BundleEvent.INSTALLED:
            System.out.println("Bundle Installed");
            printBundleCount();
            break;

        case BundleEvent.UNINSTALLED:
            System.out.println("Bundle Uninstalled");
            printBundleCount();
            break;
        }
    }

    private void printBundleCount(){
        int count=context.getBundles().length;
        System.out.println("There are currently" +count+ " bundles");
    }
}

This is the bnd.bnd file I have for the package containing the BundleCounterActivator class.

Bundle-Version: 0.0.0.${tstamp}
Private-Package:  \
    com.counter
Bundle-Activator: com.counter.BundleCounterActivator

I am trying to upload this bundle to the 'run bundle' configuration defined in the tutorial. However, I get the following error:

Unable to resolve BundleCounter version=0.0.0.201508121544:
   missing requirement Require[osgi.wiring.package]{}{filter=(&(osgi.wiring.package=org.osgi.framework)

My question: How do I install the missing package: 'org.osgi.framework' for this project (or rather, the felix osgi runtime environment setup for the tutorial project in the given link) ? Any help is appreciated.

Here are the screenshots for the steps involved:

1) Given 'run.bndrun' file

2) Adding bundle requirement

3) Error I get while trying to add 'BundleCounter'

Answer 1

When bndtools attempts to resolve a bndrun file it queries the configured repositories for the capabilities needed to match your run requirements. It does this recursively, so in this case the following is happening:

1. It encounters your requirement for the BundleCounter bundle
2. It locates the BundleCounter bundle, and finds that the BundleCounter requires the org.osgi.framework package at version [1.8,2) (i.e. at least 1.8 but less than 2.0)
3. It fails to find any provider of org.osgi.framework, and reports the failure to you.

Now org.osgi.framework is the primary package of the OSGi core specification, and is always provided by the OSGi framework. Version 1.8 of that package corresponds to OSGi Release 6 (JavaDoc here), which is the latest release of the specification. In order to satisfy it you will need a recent release of Eclipse Equinox or Apache Felix. I can see from the first picture that you're using Apache Felix, but not what version you've selected.

To get the resolve operation to work there are two options. Either you need a framework which can provide version 1.8 of the OSGi API, or you need to decrease the version of the API that you depend on.

If you want to get an OSGi Release 6 compliant Felix I would recommend using the latest release 5.0.1 from here. You will need to add it to your local repository for it to be picked up by the resolver.

Decreasing the version of your API dependency would also be very easy. You just need to decrease the version of your build dependency on osgi.core to something lower than 6. I wouldn't go any lower than 4.3.1 as that was when generics were introduced to the API, and 5 is my preferred option.

In general it's a good idea to use the lowest version of any API that you can get away with. OSGi's semantic versioning means that you know when breaking changes occur, and choosing the lowest version possible gives you maximum interoperability.