+1 these were exactly my plans :) especially changing the retention level to class file will allow us better tooling support (like using an annotation processor which could be triggered from an ide as well) and we can finally drop qdox.
If noone beats me, I'll create issues for these things and work on them in the near future. Regards Carsten 2011/11/7 Felix Meschberger <[email protected]>: > Hi all, > > The OSGi Compendium specification is taking shape and it will include a > specification for Declarative Services annotations for build-tools. This is > the same turf as we operate on with the SCR maven plugin (and ant task). > > Going forward I see the following changes, we might want to apply to the SCR > plugin: > > * drop support for JavaDoc Tags. These have been deprecated for some time now > and I think going forward we should drop them. Not the least to make the > plugin code simpler. > > * change the retention level of our own annotations from source level to > class file. This would bring the retention level in line with the upcoming > OSGi annotations and would allow us ot uniformely read the annotations from > the class files. > > * Add support for the new OSGi standard annotations, of course. > > * Consider supportig mixing Felix and standard annotations in the same class > (not a requirement but might be helpful -- or confusing ;-) ) > > * Replace the use of QDox for reading annotations by a class file annotation > reader, such as the BND library. > > * For backwards compatibility keep the support for the intermediate XML files > (OSGI-INF/scr-plugin/scrinfo.xml) we used for inheritance support. But in the > future these files will not be generated any longer and be replaced by direct > class file reading of extended classes. > > As a consequence of these changes, of course, the SCR maven plugin etc. would > be released with an increased major version number due to broken backwards > compatibilty (dropping JavaDoc tag support). Existing Java annotation use and > existing compiled and bundled code keeps being supported. > > We also, at the moment, keep our own annotations because they have a number > of advantages IMHO over the standard annotations: > - support class inheritance and abstract components > - have separate @Service annotations (with a different default for service > exposure) > - have separate @Property annotations with simpler and less cluttering syntax > - integrated Metatype descriptor support > > WDYT ? > > Regards > Felix -- Carsten Ziegeler [email protected]
