You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2016/05/12 07:18:15 UTC
[karaf-boot] New plugin system POC
We currently use java annotation processors for out starters. The
problem is that these are not integrated with maven.
So for example if we create files in the processors they will not be
added to the resulting jar.
I have created a prototype of a new plugin system based on xbean finder
and a karaf boot plugin SPI in a new branch.
See
https://github.com/apache/karaf-boot/tree/boot-plugin
The karaf-boot maven plugin uses xbean finder to scan for boot-plugins.
Each boot plugin can then define which trigger annotation it supports
and will be called
back with all classes in user code that are annotated with the
respective annotation. The plugin can then process the information and
create files as well as define additional Manifest headers.
Maven plugin
https://github.com/apache/karaf-boot/blob/boot-plugin/tools/karaf-boot-maven-plugin/src/main/java/org/apache/karaf/boot/maven/GenerateMojo.java
Boot-plugin spi
https://github.com/apache/karaf-boot/blob/boot-plugin/starters/plugin-api/src/main/java/org/apache/karaf/boot/plugin/api/BootPlugin.java
The JPA starter is currently the only starter that uses the SPI
https://github.com/apache/karaf-boot/blob/boot-plugin/starters/karaf-boot-starter-jpa/src/main/java/org/apache/karaf/boot/jpa/impl/JpaProcessor.java
The JPA sample shows how it works. I did not need to do any changes to
the example
https://github.com/apache/karaf-boot/tree/boot-plugin/samples/jpa
A good thing in the new SPI is that the user code only depends on the
plugin API it does not need access to xbean finder. I think this
approach could allow us to keep the user space quite
free of our internal dependencies if we do it well.
I talked to Guillaume about the new plugin mechanism. He would prefer to
use a bnd plugin for this. I am open to this but was not able to
implement it
in short term. The bnd API is a bit strange. Still bnd should also
provide us with all the features we need.
The current code combines the headers of all plugins into a bnd file
which is then given to the maven-bundle-plugin. One thing that does not
yet work is to
also allow the user to override some settings in his own bnd file. bnd
does not seem to allow one such file override settings defined in another.
I would be glad about any ideas how to make this work.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [karaf-boot] New plugin system POC
Posted by David Jencks <da...@yahoo.com.INVALID>.
I’m not that up on git links to classes, but the ways in to the code are from
aQute.bnd.metatype.MetatypeAnnotations
and
aQute.bnd.component.DSAnnotations
in bndlib. The “magic” annotation processing happens in AnnotationReader and OCDReader doXmlAttribute methods. The magic meta-annotation has some documentation, aQute.bnd.annotation.xml.XMLAttribute
You may want to consider adding extender requirements, I’m not sure how many of these things like JPA have spec namespaces or requirements. On the other hand I don’t know if any JPA packagings claim a kind of JPA capability.
hope this helps…. I’ll try to answer more questions after you’ve taken a look.
david jencks
> On May 12, 2016, at 12:47 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> Sounds interesting. Can you give some pointers to the respective code?
>
> Christian
>
> On 12.05.2016 09:44, David Jencks wrote:
>> I don’t quite understand what you are trying to do, but…
>>
>> You should write this as a bnd plugin. Judging by the jpa sample you show I think the (spec, not bnd proprietary) dsannotations and metatypeannotations processors in bnd would be good models to copy. Both of these scan classes in the bundle under construction and generate xml documents that go in the bundle and manifest headers from them. I’m not sure if it’s applicable to your use but Peter had this neat idea for a meta annotation that can be used on third part annotations to add additional other-namespace attributes into the generated document. I use it (publicly) for the the felix ds extension attributes (DSExt annotation in the felix scr-ext-anno project.
>>
>> david jencks
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: [karaf-boot] New plugin system POC
Posted by Christian Schneider <ch...@die-schneider.net>.
Sounds interesting. Can you give some pointers to the respective code?
Christian
On 12.05.2016 09:44, David Jencks wrote:
> I don\u2019t quite understand what you are trying to do, but\u2026
>
> You should write this as a bnd plugin. Judging by the jpa sample you show I think the (spec, not bnd proprietary) dsannotations and metatypeannotations processors in bnd would be good models to copy. Both of these scan classes in the bundle under construction and generate xml documents that go in the bundle and manifest headers from them. I\u2019m not sure if it\u2019s applicable to your use but Peter had this neat idea for a meta annotation that can be used on third part annotations to add additional other-namespace attributes into the generated document. I use it (publicly) for the the felix ds extension attributes (DSExt annotation in the felix scr-ext-anno project.
>
> david jencks
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [karaf-boot] New plugin system POC
Posted by David Jencks <da...@yahoo.com.INVALID>.
I don’t quite understand what you are trying to do, but…
You should write this as a bnd plugin. Judging by the jpa sample you show I think the (spec, not bnd proprietary) dsannotations and metatypeannotations processors in bnd would be good models to copy. Both of these scan classes in the bundle under construction and generate xml documents that go in the bundle and manifest headers from them. I’m not sure if it’s applicable to your use but Peter had this neat idea for a meta annotation that can be used on third part annotations to add additional other-namespace attributes into the generated document. I use it (publicly) for the the felix ds extension attributes (DSExt annotation in the felix scr-ext-anno project.
david jencks
> On May 12, 2016, at 12:18 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> We currently use java annotation processors for out starters. The problem is that these are not integrated with maven.
> So for example if we create files in the processors they will not be added to the resulting jar.
>
> I have created a prototype of a new plugin system based on xbean finder and a karaf boot plugin SPI in a new branch.
>
> See
> https://github.com/apache/karaf-boot/tree/boot-plugin
>
> The karaf-boot maven plugin uses xbean finder to scan for boot-plugins. Each boot plugin can then define which trigger annotation it supports and will be called
> back with all classes in user code that are annotated with the respective annotation. The plugin can then process the information and
> create files as well as define additional Manifest headers.
>
> Maven plugin
> https://github.com/apache/karaf-boot/blob/boot-plugin/tools/karaf-boot-maven-plugin/src/main/java/org/apache/karaf/boot/maven/GenerateMojo.java
>
> Boot-plugin spi
> https://github.com/apache/karaf-boot/blob/boot-plugin/starters/plugin-api/src/main/java/org/apache/karaf/boot/plugin/api/BootPlugin.java
>
> The JPA starter is currently the only starter that uses the SPI
> https://github.com/apache/karaf-boot/blob/boot-plugin/starters/karaf-boot-starter-jpa/src/main/java/org/apache/karaf/boot/jpa/impl/JpaProcessor.java
>
> The JPA sample shows how it works. I did not need to do any changes to the example
> https://github.com/apache/karaf-boot/tree/boot-plugin/samples/jpa
>
> A good thing in the new SPI is that the user code only depends on the plugin API it does not need access to xbean finder. I think this approach could allow us to keep the user space quite
> free of our internal dependencies if we do it well.
>
> I talked to Guillaume about the new plugin mechanism. He would prefer to use a bnd plugin for this. I am open to this but was not able to implement it
> in short term. The bnd API is a bit strange. Still bnd should also provide us with all the features we need.
>
> The current code combines the headers of all plugins into a bnd file which is then given to the maven-bundle-plugin. One thing that does not yet work is to
> also allow the user to override some settings in his own bnd file. bnd does not seem to allow one such file override settings defined in another.
> I would be glad about any ideas how to make this work.
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>