Carsten: -------- Original Message -------- Subject: Re: Future of the Maven SCR Plugin From: Carsten Ziegeler <[email protected]> To: [email protected] Date: Tue 08 Nov 2011 04:56:46 PM CST > 2011/11/7 Andrei Pozolotin <[email protected]>: >> 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 I have a working prototype; then I'll wait on your readiness to start bugging you :-)
> no idea about what m2e requires and what to implement, but its a you may want to start here: http://wiki.eclipse.org/M2E_Extension_Development > direction I'm definitly interested in. great! > I think once we have refactored and changed the current maven plugin, > writing such things like this connector should be much easier while refactoring now, please do not produce single monolithic xml; at least please give an option to produce one xml per component; (which is both fine per osgi spec and also I already tested with current felix scr runtime - works ok) > > Regards > Carsten thank you Andrei. > >> thanks. >> >> Andrei. >> >> >> >> -------- Original Message -------- >> Subject: Re: Future of the Maven SCR Plugin >> From: Carsten Ziegeler <[email protected]> >> To: [email protected] >> 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 <[email protected]>: >>>> 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 <[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] >>> >> > >
