Hi, Am 09.11.2011 um 02:23 schrieb Andrei Pozolotin:
>> 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) This really sounds like a good idea. And by doing this we can also solve a small problem we have today: If we have components in a bundle which use DS 1.0 and components using DS 1.1 we have to land on a common level of support for both groups of components, being DS 1.1. By using separate descriptors per component we can actually define the DS support level for each component individually. Regards Felix > >> >> Regards >> Carsten > thank you > > Andrei. > > > >> >>> 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 >>>> >>> >> >> >
