Carsten: is it feasible to include inside your plugin also m2e connector which would expose incremental build : single-component-class => single-scr-xml-file
as currently plugin is unusable in eclipse interactive mode; thanks. Andrei. -------- Original Message -------- Subject: Re: Future of the Maven SCR Plugin From: Carsten Ziegeler <cziege...@apache.org> To: dev@felix.apache.org Date: Mon 07 Nov 2011 12:20:38 PM CST > I'll cut a release of the current trunk as this contains some > important bug fixes before starting the new work > > Carsten > > 2011/11/7 Felix Meschberger <fmesc...@adobe.com>: >> 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 >> > >
