bndlib 4.1.0 breaks @Reference

[realPyR3X]

Hello,

I've updated to bndlib 4.1.0 from 4.0.0 and the following now occurs:

@Reference
protected transient IoListener ioListener;

now causes during build:

[In component , field ioListener, cannot recognize the signature of the descriptor: Lcom/example/spi/IoListener;, No interface specified on ioListener]

in karaf 4.2.0:

missing requirement [com.example.testio/1.0.0.SNAPSHOT] osgi.service; filter:="(objectClass=null)"; effective:=active]]

[bjhargrave]

As you can imagine, we have many tests for field references. Perhaps the 'transient" modifier is confusing. Try removing it.

Otherwise, can you may a small github repo to show the problem so it can be debugged?

On Wed, Oct 17, 2018 at 11:29 PM realPyR3X notifications@github.com wrote:

Hello,

I've updated to bndlib 4.1.0 from 4.0.0 and the following now occurs:

@reference https://github.com/reference protected transient IoListener ioListener;

now causes during build:

[In component , field ioListener, cannot recognize the signature of the descriptor: Lcom/example/spi/IoListener;, No interface specified on ioListener]

in karaf 4.2.0:

missing requirement [com.example.testio/1.0.0.SNAPSHOT] osgi.service; filter:="(objectClass=null)"; effective:=active]]

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bndtools/bnd/issues/2680, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ8srCPcpifYomzOOCam6ULGRmcSA00ks5ul_WSgaJpZM4Xsmc1 .

--

BJ

[realPyR3X]

I've verified the issue is not from 'transient'. I will create a github repo to demonstrate when I can. I should note there is no issue with the following. This only occurs with a single @Reference

This works:

@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
protected transient List<Store> stores;

There is also a separate issue I identified when creating a fragment bundle to org.apache.karaf.webconsole. See below:

Fragment-Host', 'org.apache.karaf.webconsole.console;bundle-version="[3,5)"

causes:

[Host org.apache.karaf.webconsole.console=bundle-version="[3,5)" for this fragment cannot be found on the classpath]

This won't be part of the classpath because it's part of the deployment environment (Karaf)

[bjhargrave]

There is also a separate issue I identified when creating a fragment bundle to org.apache.karaf.webconsole. See below:

'Fragment-Host', 'org.apache.karaf.webconsole.console;bundle-version="[3,5)"'

causes:

[Host org.apache.karaf.webconsole.console=bundle-version="[3,5)" for this fragment cannot be found on the classpath]

This won't be part of the classpath because it's part of the deployment environment (Karaf)

So you will need put it on the -buildpath of the project or make a -fixupmessages instruction to elide this warning.

[bjhargrave]

I've verified the issue is not from 'transient'. I will create a github repo to demonstrate when I can.

You can probably work around this by explicitly specifying the service

@Reference(service=IoListener.class)
protected transient IoListener ioListener;

Then Bnd does not need to infer the service type.

[djencks]

How can bndlib do better with IoListener.class than the IoListener type in the method signature? I don’t remember the exact rules for service type inference but I wondered if IoListener is a concrete class rather than an interface and that requires you to specify explicitly that you mean that class for the service type; this would not be a workaround.

david jencks

On Oct 18, 2018, at 11:56 AM, BJ Hargrave notifications@github.com wrote:

I've verified the issue is not from 'transient'. I will create a github repo to demonstrate when I can.

You can probably work around this by explicitly specifying the service

@Reference(service=IoListener.class) protected transient IoListener ioListener; Then Bnd does not need to infer the service type.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bndtools/bnd/issues/2680#issuecomment-431122313, or mute the thread https://github.com/notifications/unsubscribe-auth/AAix3vn6C-X1FYVTyGw4AxKRHOCSEd8Eks5umM7egaJpZM4Xsmc1.

[bjhargrave]

How can bndlib do better with IoListener.class than the IoListener type in the method signature?

It is possible IoListener is a generic type. Or a subclass of Collection. Or both. The type inferencing code was completely rewritten for 4.1. See https://github.com/bndtools/bnd/blob/master/biz.aQute.bndlib.tests/test/aQute/bnd/signatures/TypeUser1.java for examples of what is supported now.

[realPyR3X]

IoListener is a simple interface that does not extend anything. The 'service' should be inferred from the type and the 'cardinality' is 1..1 based on not be a collection.

The inferencing code must be making a mistake because it does the right thing with collection types.

[bjhargrave]

Well, we do have lots of tests, and I have used Bnd 4.1 with field references just fine. So there must be something different about your build setup. So once you can make a github repo to demonstrate the problem, we can investigate it.

[realPyR3X]

See this project. This issue only arrises after something becomes an SCR component @Component)

https://github.com/realPyR3X/osgi-bnd-test

[realPyR3X]

The field type inference I believe is broke in that it thinks you will always reference a collection. In this case I am simply looking to reference a single implementation with cardinality 1..1.

[stbischof]

you are using apply plugin: 'org.dm.bundle' as osgi gradle build plugin.

afaik latest released version is from 2017-01-02 17:05 uses (biz.aQute.bndlib:3.3.0) http://central.maven.org/maven2/org/dm/gradle/gradle-bundle-plugin/0.10.0/

where do you use bnd 4.1.0?

[realPyR3X]

In the build.gradle I put it on the classpath to override 3.3.0 with 4.1.0. You'll notice if you change 4.1.0 to 4.0.0 and build everything works correctly. Changing to 4.1.0 will break.

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'biz.aQute.bnd:biz.aQute.bndlib:4.1.0'
    }
}

[bjhargrave]

I have no idea how org.dm.bundle drives bndlib. So it is quite possible it is not configuring the Bnd Builder properly.

I won't have time to look into this in any more detail until after EclipseCon since I will be there all next week.

In the mean time, you may want to consider moving to the biz.aQute.bnd.builder plugin which is what I would do next to test you build with the complete Bnd gradle setup.

[realPyR3X]

Fair enough. I actually planned to move to 'biz.aQute.bnd.builder' over the weekend as 'org.dm.bundle' is no longer maintained. I'll follow up here if this resolved the issue.

Thanks

[bjhargrave]

This appears to be some bug in the org.dm.bundle plugin. I modified your build to show the compile path for the core project:

task compilePath {
  doFirst {
    println sourceSets.main.compileClasspath.asPath
  }
}

The output shows:

$ ./gradlew :core:compilePath

> Task :core:compilePath
/Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/org.osgi.service.component/1.3.0/8feb4c47c1d18422ce2f5300dd492a2fe94fc295/org.osgi.service.component-1.3.0.jar:/Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/org.osgi.service.component.annotations/1.3.0/ef17ec0e7f73cd144599da108d72a24285d1f5d5/org.osgi.service.component.annotations-1.3.0.jar:/Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/org.osgi.service.metatype.annotations/1.3.0/793a335fb4d18190a2e7a89614001c65853c91c5/org.osgi.service.metatype.annotations-1.3.0.jar:/Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/osgi.core/6.0.0/c49acdc9ac62cf69ee49cb6f1905b4fdb79ea5c/osgi.core-6.0.0.jar:/Users/hargrave/.gradle/caches/modules-2/files-2.1/org.ops4j.pax.logging/pax-logging-api/1.10.1/38413000a17c133607de8fddd461fc5240b78241/pax-logging-api-1.10.1.jar:/Users/hargrave/git/tmp/osgi-bnd-test/spi/build/classes/java/main

At the end you can see the spi project's classes are present: /Users/hargrave/git/tmp/osgi-bnd-test/spi/build/classes/java/main

But the debug output from Gradle shows:

17:45:13.891 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting classpath /Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/org.osgi.service.component/1.3.0/8feb4c47c1d18422ce2f5300dd492a2fe94fc295/org.osgi.service.component-1.3.0.jar
17:45:13.894 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting source path /Users/hargrave/git/tmp/osgi-bnd-test/core/src/main/java
17:45:13.899 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting resources /Users/hargrave/git/tmp/osgi-bnd-test/core/build/classes/java/main
17:45:13.901 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting version 1.0.0.SNAPSHOT
17:45:13.902 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting name com.example.core
17:45:13.903 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting trace false
17:45:13.904 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting fail on error false
17:45:14.003 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] The Builder is about to generate a jar using classpath: [/Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/org.osgi.service.component/1.3.0/8feb4c47c1d18422ce2f5300dd492a2fe94fc295/org.osgi.service.component-1.3.0.jar, /Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/org.osgi.service.component.annotations/1.3.0/ef17ec0e7f73cd144599da108d72a24285d1f5d5/org.osgi.service.component.annotations-1.3.0.jar, /Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/org.osgi.service.metatype.annotations/1.3.0/793a335fb4d18190a2e7a89614001c65853c91c5/org.osgi.service.metatype.annotations-1.3.0.jar, /Users/hargrave/.gradle/caches/modules-2/files-2.1/org.osgi/osgi.core/6.0.0/c49acdc9ac62cf69ee49cb6f1905b4fdb79ea5c/osgi.core-6.0.0.jar, /Users/hargrave/.gradle/caches/modules-2/files-2.1/org.ops4j.pax.logging/pax-logging-api/1.10.1/38413000a17c133607de8fddd461fc5240b78241/pax-logging-api-1.10.1.jar, /Users/hargrave/git/tmp/osgi-bnd-test/core/build/classes/java/main]
17:45:14.003 [DEBUG] [aQute.bnd.osgi.Builder] build

You will note the classpath provided to the Bnd Builder does NOT include the spi project. So Bnd cannot find the Test class and thus fails to understand what the class actually is. For example, it could be a Collection subtype.

So I am closing this since it is not a bug in Bnd but rather in how the org.dm.bundle plugin configures the Bnd Builder.

[realPyR3X]

I can confirm that this is a bug with org.dm.bundle. I have since moved to the official bnd Gradle plug-in and there are no longer any issues.

V/r,

-Charlie

[bjhargrave]

Note: See https://github.com/bndtools/bnd/pull/2849 for changes to the DS annotation processing to better handle cases where the referenced type cannot be located.