2011/11/7 Andrei Pozolotin <andrei.pozolo...@gmail.com>: > 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; > Sure, and contributions are welcome of course :) At the moment I have no idea about what m2e requires and what to implement, but its a direction I'm definitly interested in. I think once we have refactored and changed the current maven plugin, writing such things like this connector should be much easier
Regards Carsten > 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 >>> >> >> > > -- Carsten Ziegeler cziege...@apache.org
