On Apr 20, 2017 8:04 AM, "Peter Kriens" <peter.kri...@aqute.biz> wrote:
> On 20 Apr 2017, at 14:02, Tim Ward <tim.w...@paremus.com> wrote: > > Peter - I assume that you mean that there will be no auto-generated osgi.service capability. Couldn't that be fixed with an additional annotation on the component type to add the Provide-Capability to the manifest? Yes, that would solve this issue. Presumably this could be @aQute.bnd.annotation.headers.ProvideCapability, or come R7, @org.osgi.annotation.bundle.Capability . [I'm assuming that the R7 @Capability Is @Repeatable, which would imply jdk8 to compile?] 1. Both of these annotations have a "version" parameter, whose value is constrained to be a String form of an OSGI format Version. However, capabilities in the osgi.service namespace, are not versioned (and are not prohibited from using the tag "version" for an uninterrupted String attribute). The osgi.contract namespace uses the tag "version" for an attribute of type List<Version> (though the api document for the constant contradicts the text, this appears to be an error). 2. It is not clear what the relationship is between the properties that may be specified in the standard for registering a service (eg Driver name for a DataSourceProvider) and the attributes that should be included in an advertised capability for example, what attributes are required, and what typing should be used. Having to cast values in a filter to the type of a value is inefficient (iir, typing was/is implicit in the attribute specification for DAP/LDAP). This doesn't play well when using an RDBMS. I haven't quantified this issue yet (the compact index for nexus repositories doesn't have the capability fields populated, though support is now included in the index reader libraries).
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
