pax-cdi-api's OSGi MANIFEST.MF resolution:=optional for javax.enterprise.* [PAXCDI-230]

[ops4j-issues]

INACTIVE Michael Vorburger.ch created PAXCDI-230

I'd like to use the @OsgiServiceProvider and @OsgiService annotations from pax-cdi-api with the Apache Aries blueprint-maven-plugin, and am finding that the pax-cdi-api bundle's OSGi MANIFEST has what I'd argue is a bug:

Its POM has javax.enterprise:cdi-api as a <provided> dependency. So if you depend on this artefact, you don't automatically transitively get that JAR - which is a Good Thing - I'm only interested in @OsgiServiceProvider and @OsgiService and don't want EE annotations in an applications targeting Apache Karaf..

BUT the MANIFEST.MF has an Import-Package for packages javax.enterprise.context and javax.enterprise.util, so in Karaf I got the following missing dependency:

Error executing command: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=odl-infrautils-caches-sample; type=karaf.feature; version="[1.1.0.SNAPSHOT,1.1.0.SNAPSHOT]"; filter:="(&(osgi.identity=odl-infrautils-caches-sample)(type=karaf.feature)(version>=1.1.0.SNAPSHOT)(version<=1.1.0.SNAPSHOT))" [caused by: Unable to resolve odl-infrautils-caches-sample/1.1.0.SNAPSHOT: missing requirement [odl-infrautils-caches-sample/1.1.0.SNAPSHOT] osgi.identity; osgi.identity=org.ops4j.pax.cdi.api; type=osgi.bundle; version="[1.0.0.RC2,1.0.0.RC2]"; resolution:=mandatory [caused by: Unable to resolve org.ops4j.pax.cdi.api/1.0.0.RC2: missing requirement [org.ops4j.pax.cdi.api/1.0.0.RC2] osgi.wiring.package; filter:="(&(osgi.wiring.package=javax.enterprise.context)(version>=1.1.0)(!(version>=2.0.0)))"]]

This could be worked around of course, but I seems wrong that you have to have javax.enteprise? IMHO it would be more correct if javax.enterprise.* was resolution:=optional.

Thanks to FELIX-2809, resolution:=optional actually gets added to the MANIFEST if in the POM a dependency is marked as <optional>true.

I'll raise a pull request proposing this change...

---

Affects: 1.0.0.RC1 Fixed in: 1.0.0 Votes: 0, Watches: 3

[ops4j-issues]

INACTIVE Michael Vorburger.ch commented

https://ops4j1.jira.com/browse/PAXCDI-230

[ops4j-issues]

Grzegorz Grzybek commented

Hmm, OsgiServiceProvider uses @Nonbinding annotation which has retention=Runtime...

import javax.enterprise.util.Nonbinding

Will it really work with optional import of javax.enterprise.*?

[ops4j-issues]

Grzegorz Grzybek commented

OK - I just had to check it. The change is OK according to information contained in https://bugs.openjdk.java.net/browse/JDK-6322301.

If you have class annotated with unknown annotations, it must be ignored. So if you load class that has @org.ops4j.pax.cdi.api.OsgiServiceProvider annotation which has field with @javax.enterprise.util.Nonbinding annotation and javax.enterprise package is not available, that's fine.

[ops4j-issues]

Grzegorz Grzybek commented

And simply OsgiServiceProvider.class.getMethod("classes").getDeclaredAnnotations() returns 0-size array, even if there's:

@javax.enterprise.util.Nonbinding
Class<?>[] classes() default { };

when cdi-api bundle is available, we get correct:

result = {java.lang.annotation.Annotation[1]@6060} 
 0 = {com.sun.proxy.$Proxy41@6061} "@javax.enterprise.util.Nonbinding()"

(these were notes to myself actually)

[ops4j-issues]

Grzegorz Grzybek commented

I'm still reluctant however... pax-cdi-api is all about ... cdi-api... Why would you need some annotations without javax.enterprise package? You have to at least process them by other pax-cdi bundle which would definitely require javax.enterprise. And if you need some annotations, you can create your own :wink:

[ops4j-issues]

Christian Schneider commented

For the usage in blueprint-maven-plugin the annotations are not needed at runtime but for pax-cdi itself they are needed as far as I know. So I think making them optional is not a good idea.

What worked for me is to depend on pax-cdi-api with optional=true in the user bundle.
Like https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-blueprint-cdi/pom.xml#L27-L32

[ops4j-issues]

INACTIVE Michael Vorburger.ch commented

Right ... I may have simply been missing the depend on pax-cdi-api with optional=true ..

I'll re-test in the context of where I ran into this, and probably close this issue.

[ops4j-issues]

INACTIVE Michael Vorburger.ch commented

FTR: The root cause of my confusion was trying to use <optional>true via a transitive Maven dependency, which cannot work. In a parent POM (or if repeated in leaf projet POM) it does work as intended however.

Closing with resolution Works as Designed.