0

I'm pretty new to osgi and bndtools, but in the past couple days have managed to get jar->bundle creation working using bnd ant task, plus wrapping of our 3rd party jars as bundles (for those not already defining an 'Export-Package' in the manifest file). I must comment that bndtools seems amazing for doing all the heavy lifting when it comes to exports and imports, so thank you to your hard work on this project!

i've got two issues that maybe you can shed some light on:

1

I'm trying to get the bundles to load in felix and am immediately running into resolution errors. In this basic scenario, we have our in-house bundle called omniquery_common, which uses several 3rd party jars, including gson. when i resolve i get this:

Unable to resolve <<INITIAL>> version=null:
   missing requirement Require[osgi.identity]{}{filter=(osgi.identity=omniquery_common)} [caused by:
   Unable to resolve omniquery_common version=1.0.0.0:
   missing requirement Require[osgi.wiring.package]{}{filter=(&(osgi.wiring.package=com.google.gson)(version>=2.2.0)(!(version>=3.0.0)))}]

To me this says omniquery_common is importing com.google.gson (of a version at least 2.2 and less than 3.0). the gson bundle is exporting version 2.2.4, so this should satisfy its dependency, but is not.

can you help me understand how i am wiring this up wrong?

manifest for omniquery_common:

Manifest-Version: 1.0
Bnd-LastModified: 1442336803995
Bundle-ManifestVersion: 2
Bundle-Name: omniquery_common
Bundle-SymbolicName: omniquery_common
Bundle-Version: 1.0.0.0
Created-By: 1.8.0_40 (Oracle Corporation)
Export-Package: com.radian6.omni.common.osgi;version="1.0.0"
Import-Package: com.google.gson;version="[2.2,3)",com.radian6.omni.commo
 n.util,org.apache.commons.io;version="[1.4,2)",org.apache.commons.lang;
 version="[2.6,3)",org.junit
Private-Package: com.radian6.omni.common.core
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
Tool: Bnd-2.4.1.201501161923

manifest for gson:

Manifest-Version: 1.0
Export-Package: com.google.gson;version=2.2.4, com.google.gson.annotat
 ions;version=2.2.4, com.google.gson.reflect;version=2.2.4, com.google
 .gson.stream;version=2.2.4, com.google.gson.internal;version=2.2.4, c
 om.google.gson.internal.bind;version=2.2.4
Bundle-ClassPath: .
Built-By: inder
Bundle-Name: Gson
Created-By: Apache Maven 3.0.4
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-Vendor: Google Gson Project
Bundle-ContactAddress: http://code.google.com/p/google-gson/
Bundle-Version: 2.2.4
Build-Jdk: 1.7.0_21
Bundle-ManifestVersion: 2
Bundle-Description: Google Gson library
Bundle-SymbolicName: com.google.gson
Archiver-Version: Plexus Archiver

2

if i alter the order of the bundles in the 'run requirements' list, putting the gson bundle before omniquery_common, i then get 

Unable to resolve <<INITIAL>> version=null:
   missing requirement Require[osgi.identity]{}{filter=(osgi.identity=com.google.gson)}

which i find unintuitive - i would have thought the bundle order in that list would not matter...?

Adam Morgan
  • 425
  • 1
  • 3
  • 17

1 Answers1

0

The order of the requirements in the -runrequirements list does matter, because if there is an error early in the list then we don't bother trying to resolve everything below it. That is: once we know that the resolution cannot succeed, we just exit and print the first error we encountered.

The second error message you copied (when you put the GSON requirement first) suggests that you simply don't have the GSON bundle in your repository. Or, it is not in a repository that is visible to the resolver. The filter (osgi.identity=com.google.gson) fails, which means there is no resource with the identity com.google.gson.

This would also explain the first error message from your own omniquery_common bundle. The resolver cannot find any bundle exporting the package com.google.gson, which would make perfect sense if the GSON bundle is not there.

So, look into the repositories you are resolving against and what their indexes contain. If GSON really does appear to be in there, then I will need further info on to figure out the problem.

Incidentally, once you have this working, you shouldn't need to list GSON explicitly at all in -runrequirements. That is the point of the resolver: we will find all your dependencies based on the packages you used.

Neil Bartlett
  • 23,743
  • 4
  • 44
  • 77
  • Ok that makes sense for runrequirements in that sense, but I thought I read somewhere that osgi permits circular dependencies. Wouldn't this 'short circuit' prevent this? – Adam Morgan Sep 21 '15 at 19:20
  • In any case, I realized that I had been creating separate Run Descriptors. Once I deleted those and used the default bnd.bnd file (didn't realize at first that you could put the run descriptor in there) things started working. However, I still need to put the bundle in the 'run requirements' because it doesn't seem to be auto-resolving the dependencies. In any case, I have my basic setup working, with a BundleActivator getting started. thanks Neil! – Adam Morgan Sep 21 '15 at 19:22
  • Yes OSGi permits circular dependencies. I don't see how this is relevant... where is the circular dependency here? You just have a completely absent bundle. – Neil Bartlett Sep 22 '15 at 11:17
  • Yah, there's absolutely no circ dep here - it was just your statement about short circuiting that made it sound like if it hadn't already found the dependency that it fails fast. In that case of a circ dep, then you would need to potentially go to the end of the list before finding the other bundle in your circ dep, and short circuiting sounds like it would prevent that full traverse of runrequirements. Does that make any sense? – Adam Morgan Sep 23 '15 at 11:56
  • The list of top-level requirements isn't really relevant, because you could get a cycle in any of the nth-level dependencies of those requirements. And the resolver handles them simply by remembering the resources it has already visited. Anyway, I didn't write a resolver but I know it works so I'm happy. – Neil Bartlett Sep 23 '15 at 19:59
  • So I have gotten everything working with a standalone felix installation. However, when I come back to bndtools in eclipse, with all my appropriate bundles listed under 'available bundles', i get errors about missing `Failed to start bundle omniquery_service-1.0.0, exception Unresolved constraint in bundle omniquery_service [6]: Unable to resolve 6.0: missing requirement [6.0] osgi.wiring.package; (osgi.wiring.package=com.radian6.buildup)` the buildup.jar bundle is there, and its manifest exports com.radian6.buildup. what am i missing here? – Adam Morgan Sep 25 '15 at 18:18