Hi Robert, In a broader scope this will happen for RFC 0172 Declarative Services Annotations (runtime processing of SCR components), however this brings with it standardised annotations.
cheers, Caspar On 13 April 2012 13:33, Robert Munteanu <[email protected]> wrote: > Hi, > > I've noticed that the annotations from org.apache.felix.scr.annotations > are declared with @Retention(RetentionPolicy.SOURCE) . I think the > following use cases would benefit from the annotations being available at > runtime . > > 1. Configuring component instances outside a OSGi container > > I often develop components which I want to test in plain JUnit tests > rather than in a container. These components have references which I need > to satisfy in order for the unit test to run. Since the annotations are > available only in the source file, I am unable to inspect the declared > references and inject them in a generic manner. > > The alternative is to manually configure each reference, but that gets > tedious pretty fast. > > 2. Processing SCR annotations in a JSR-269 annotation processor > > Having the annotations available to the processor ( strictly speaking only > RetentionPolicy.CLASS is required ) would allow much simpler integration of > SCR processing since the processor would only need to be available as a JAR > on the compile classpath, rather than a separate maven plugin invocation or > explicit ant task call. > > Above the other two use cases, having annotations at runtime can generally > ease integration with other systems which can inspect the component > configuration at runtime. > > The single downside that I see is that the annotations will increase the > file size of the deployed bundles ( although I don't think it will be a > huge increase ). > > I'm willing to prepare a patch, but would like your opinion first. > > Thanks, > > Robert >
