felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Pozolotin <andrei.pozolo...@gmail.com>
Subject Re: Future of the Maven SCR Plugin
Date Wed, 09 Nov 2011 01:23:51 GMT

-------- Original Message  --------
Subject: Re: Future of the Maven SCR Plugin
From: Carsten Ziegeler <cziegeler@apache.org>
To: dev@felix.apache.org
Date: Tue 08 Nov 2011 04:56:46 PM CST
> 2011/11/7 Andrei Pozolotin <andrei.pozolotin@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
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:


> 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
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


>> thanks.
>> Andrei.
>> -------- Original Message  --------
>> Subject: Re: Future of the Maven SCR Plugin
>> From: Carsten Ziegeler <cziegeler@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 <fmeschbe@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 <fmeschbe@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
>>>>>> * 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
>>>>>>  - integrated Metatype descriptor support
>>>>>> WDYT ?
>>>>>> Regards
>>>>>> Felix
>>>>> --
>>>>> Carsten Ziegeler
>>>>> cziegeler@apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message