Hi, Am 07.11.2011 um 18:48 schrieb Carsten Ziegeler: > +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.
Go, Carsten, go ! ;-) Regards Felix > > Regards > Carsten > > 2011/11/7 Felix Meschberger <fmesc...@adobe.com>: >> 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 > cziege...@apache.org
