Resolve issue using biz.aQute.tester.junit-platform

I just discovered the OSGi Test project and I’m trying it with JUnit 5 in Bndtools. I’m seeing the following when doing a Resolve on my test bundle. I understand that osgi.cmpn is compile only but I don’t the general approach to handling this situation.
I have junit-platform listed in the Bnd runrequires: clause.

Resolution failed. Capabilities satisfying the following requirements could not be found:
⇒ osgi.identity: (osgi.identity=biz.aQute.tester.junit-platform)
[osgi.cmpn version=]
⇒ osgi.unresolvable: (&(must.not.resolve=)(!(must.not.resolve=)))

Thanks, Scott

You should not use osgi.cmpn any more. It is recommended to use the individual API jars for each spec you use. To prevent people from installing (and resolving) osgi.cmpn, its manifest requires the osgi.unresolvable capability which the resolver can never satisfy.

If you must use osgi.cmpn as a compile scope dependency, then you would need to tell the resolved to never use it.

-runblacklist: osgi.identity;filter:='(osgi.identity=osgi.cmpn)'

However, if you do that, you will need to supply other bundles, such as the individual API jars to enable a successful resolution.

The best solution is to completely avoid osgi.cmpn :slight_smile:

I thought the message was telling me that junit-platform was using osgi.cmpn. Am I mistaken on that? Is that not the case?

I don’t think so. It is saying the resource osgi.cmpn was added to the resolution solution but that osgi.cmpn requires an osgi.unresolvable capability and that cannot be satisfied.

Ok, thanks. I was wondering why there wasn’t a osgi.cmpn 8.0. I wasn’t aware that had fallen out of favor.

Toward that end, are there predefined repos that can be referenced that have all the OSGi R8 apis and reference implementations defined like this is for Enroute with R7? Seems reasonable that these would exist.

All the R8 API jars are in Maven Central. However, there is no BOM like what enRoute provided since it would echo the problems of osgi.cmpn which creates a bad coupling between versions of completely independent APIs. Each application would need to decide which APIs to use and at what versions. Generally you want compile using the lowest API version which meets your needs. Then you can run against an implementation of that API version or any later version.

Most implementations are probably also available from Maven Central.