Hi Caspar, Thanks for your reply. I've glanced over http://www.osgi.org/download/osgi-early-draft-2011-09.pdf and noticed that the annotations are defined with @Retention(value=RetentionPolicy.CLASS) . I've also found that the same will happen with the SCR annotations from Felix in the next release ( https://issues.apache.org/jira/browse/FELIX-3247 ) .
That means that the annotations will not be available at runtime, so I will not be able to configure components by myself in unit tests. I assume that Felix annotations will follow the official ones, so it makes little sense to argue for making them available at runtime. Robert > -----Original Message----- > From: Caspar MacRae [mailto:[email protected]] > Sent: Friday, April 13, 2012 3:48 PM > To: [email protected] > Subject: Re: Proposal to make org.apache.felix.scr.annotations > available at Runtime > > 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 > >
