[component property types] make component property type annotations retention RUNTIME

[bjhargrave]

Original bug ID: BZ#3015 From: @rotty3000 Reported version: R7

[bjhargrave]

Comment author: @rotty3000

If we don't then other frameworks which do runtime annotation processing can't use them. E.g. CDI, blueprint, etc.

[bjhargrave]

Comment author: @bjhargrave

Making them runtime retention means that there is a runtime reference to them and your bundle must import the package or they will be silently elided from your runtime annotations.

See https://osgi.org/members/bugzilla/show_bug.cgi?id=2967#c3 for a similar discussion about runtime retention.

If we want to make ComponentPropertyType itself runtime retention, then we should move it out of the org.osgi.service.component.annotations package so that bundles do not need to import that package at runtime if they want to see ComponentPropertyType annotated things.

[bjhargrave]

Comment author: @timothyjward

(In reply to Raymond Auge from comment BZ#0)

If we don't then other frameworks which do runtime annotation processing can't use them. E.g. CDI, blueprint, etc.

The Blueprint specification doesn't do runtime annotation processing, or declare any annotations, so this really only applies to CDI and to non-standard things like ipojo (which I'm pretty sure doesn't do runtime scanning either). CDI is the only proposed standard that would use this.

Component Property Types are defined by Declarative Services. If we were to make them consumable by CDI then it would involve moving them to their own specification, and to their own package. As BJ says this would create a runtime link, even when the annotations aren't being used at runtime, and it would become much harder to understand the annotation usage.

It seems to me as though the OSGi CDI specification needs to define its own meta-annotation which can be used to set service properties for CDI in a way which makes sense to CDI.

[bjhargrave]

Comment author: @rotty3000

(In reply to Tim Ward from comment BZ#2)

(In reply to Raymond Auge from comment BZ#0)

If we don't then other frameworks which do runtime annotation processing can't use them. E.g. CDI, blueprint, etc.

The Blueprint specification doesn't do runtime annotation processing, or declare any annotations, so this really only applies to CDI and to non-standard things like ipojo (which I'm pretty sure doesn't do runtime scanning either). CDI is the only proposed standard that would use this.

Component Property Types are defined by Declarative Services. If we were to make them consumable by CDI then it would involve moving them to their own specification, and to their own package. As BJ says this would create a runtime link, even when the annotations aren't being used at runtime, and it would become much harder to understand the annotation usage.

It seems to me as though the OSGi CDI specification needs to define its own meta-annotation which can be used to set service properties for CDI in a way which makes sense to CDI.

The problem here is that "standard" CPT are being defined now by other specs. Does that mean that once CDI defines its own mechanism then these other specs will again need to define "standard" annotations for this mechanism? If they don't, are we saying that CDI is a second class citizen?

[bjhargrave]

Comment author: @timothyjward

The problem here is that "standard" CPT are being defined now by other specs.

Well the DS spec is defining a DS specific meta annotation which can be used to set DS Component Properties. It's "standard" in that it's part of DS, but it's not currently defined in a way which is reusable outside of DS. Specifically, there is no CPT standard, there is a DS standard which defines a CPT for use in DS.

Does that mean that once CDI defines its own mechanism then these other specs will again need to define "standard" annotations for this mechanism?

Yes, if and when another component model comes along it will need to make its own decisions about what, if any, annotations are supported and how they are used. If it becomes clear that there could be a common property annotation specification used by multiple component models then that would be something to look at in Release N+1. Right now we have two specs that could potentially use the Component Property Types, but I don't see very much commonality between them.

• DS annotations are completely build-time, CDI is completely runtime
• DS property annotations define component properties which do much more than just set service properties (e.g. I can use them to set target filters and reference cardinailties), as far as I am aware CDI has no equivalent
• CDI has a large set of existing annotation driven behaviours which don't necessarily fit with the model we have now in DS.

Given these significant differences I'm unconvinced that changing the currently accepted DS model is a good idea. If we were to make changes I would certainly want a good, long discussion about what we're aiming for and lots of time for it to bed in.

[bjhargrave]

Comment author: @bjhargrave

CPEG call: Defer this until we add CDI to spec.

[bjhargrave]

Comment author: @bjhargrave

CPEG call: Closing. If runtime retention is needed, new annotations will be defined.