I just wasted an hour trying to figure out why my test was complaining about
missing the `org.osgi.service.component` package. The Apache Felix SCR bundle I
was using was clearly exporting and importing it. Since I was testing launchpad
I blamed myself so I dug deep into things but could not figure it out.
Until I realized I had SCR in my repository twice.
Reasonable people would assume that 2.0.10.v20170501-2007 is the same bundle as
2.0.10 so I only looked at the first one, the original Apache Felix. Until I
finally became desperate enough and looked at the Eclipse version, which indeed
turned out to be a variation.
Apache Felix original:
Export-Package
org.apache.felix.scr.component {version=1.1.0, imported-as=[1.1,1.2)}
org.apache.felix.scr.info {version=1.0.0, imported-as=[1.0,1.1)}
org.osgi.service.component {version=1.3, imported-as=[1.3,1.4)}
org.osgi.service.component.runtime {version=1.3, imported-as=[1.3,1.4)}
org.osgi.service.component.runtime.dto {version=1.3, imported-as=[1.3,1.4)}
org.osgi.util.function {version=1.0, imported-as=[1.0,2)}
org.osgi.util.promise {version=1.0, imported-as=[1.0,2)}
The Eclipse variation:
Export-Package
org.apache.felix.scr.component {version=1.1.0, imported-as=[1.1,1.2)}
org.apache.felix.scr.info {version=1.0.0, imported-as=[1.0,1.1)}
This is just wrong. If you wrap a bundle and change its signature you **must**
give it a new name because you fundamentally modify the public API. You do not
own that other person's namespace! Just changing the micro/patch part of the
version is just wrong. These kind of self inflicted wounds cause imho the most
pain in software development.
That all said, it does make another case for the resolver. If I'd used that one
I'd seen it immediately.
Kind regards,
Peter Kriens
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
