karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [DISCUSSION] Karaf Boot
Date Thu, 10 Sep 2015 14:44:41 GMT
I like the idea.

For the annotations, we need to keep really high level.  The annotations in
the code base right now are much too close to blueprint.
I think we need to grab a small enough subset so that the annotations are
easy to understand for beginners and without any ambiguities, even at the
cost of features.
For example, I think we should restrict to constructor injection, so that
we don't have any bind / rebind / init methods.  We simply need an optional
@Destroy.  In case the dependencies change at runtime, simply destroy the
bean / service and recreate it the dependencies are still met after the

If blueprint is to be hidden completely, we may find a better alternative
in SCR or even Felix Dependency Manager, but it does not matter too much
for now.

I agree with the idea of using a BOM instead of a parent if possible.  I'm
not very familiar, but this is less invasive.

The real problems will come with the support of higher level annotations
for JAXRS, JPA, etc...
Not really sure how to handle those yet...

2015-09-09 16:32 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

> Hi all,
> I worked on a prototype about Karaf Boot.
> Let me give you some backgrounds and discuss about that all together.
>  Why Karaf Boot ?
>  ----------------
> When you develop artifacts (bundles) to be deployed in Karaf, you can see
> that the actual time that you spend on your business code is finally
> largely less important that all the plumbing effort that you have to do
> (writing OSGi Activator, or blueprint/scr descriptor, etc).
> It means that your "go to market" is longer, and we should provide
> something that allows you to focus on your code.
> Even if SCR annotations is a very good step forward, some use cases are
> not so easy to do (JPA, JTA for instance).
> And anyway, you have to prepare your pom.xml with different plugin and
> dependency.
> Moreover, when you have your artifacts, you have to prepare Karaf
> container, and deploy those artifacts there. Even if it's "container"
> approach is the most important for me, we can give even more flexibility by
> providing a way to embed and prepare Karaf in a ready to execute
> jar/artifact.
>  What is Karaf Boot ?
>  --------------------
> Karaf Boot provides four components:
> * karaf-boot-parent is the Maven parent pom that your project just
> inherit: that's all ! All plugins, dependencies, etc are described in this
> parent, you even don't have to define packaging as bundle, standard jar is
> fine.
> * karaf-boot (coming with karaf-boot-parent) provides annotations that you
> use directly in your business code (like @Bean, @Service, @Reference,
> @Inject, etc): again, your focus on your code, karaf-boot deals with the
> plumbing.
> * karaf-boot-maven-plugin (coming with karaf-boot-parent) scan the classes
> and generate a blueprint XML. For now, I'm using blueprint generation
> (because we can cover lot of use cases, for instance, I plan to provide
> @rest annotation that will generate blueprint XML with cxf jaxrs server,
> etc).
> * karaf-boot-starter is the module providing a convenient way to embed,
> configure and bootstrap Karaf.
> Just to illustrate this, let's take a look on the karaf-boot-sample-simple.
> The pom.xml is really simple:
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd">
>     <modelVersion>4.0.0</modelVersion>
>     <parent>
>         <groupId>org.apache.karaf.boot</groupId>
>         <artifactId>karaf-boot-parent</artifactId>
>         <version>1.0.0-SNAPSHOT</version>
>     </parent>
>     <artifactId>karaf-boot-sample-simple</artifactId>
>     <version>1.0.0-SNAPSHOT</version>
> </project>
> You can see, the only thing that the developer has to do: define
> karaf-boot-parent as parent pom. That's all.
> Now, in the code, you have just one bean that we want to run:
> package org.apache.karaf.boot.sample.simple;
> import org.apache.karaf.boot.Bean;
> import org.apache.karaf.boot.Init;
> @Bean(id = "simple-bean")
> public class SimpleBean {
>     @Init
>     public void simple() {
>         System.out.println("Hello world");
>     }
> }
> You can see the @Bean and @Init karaf-boot annotations. The
> karaf-boot-maven-plugin will generate the blueprint descriptor using this.
>  Current Status
>  --------------
> I pushed Karaf Boot structure there:
> https://github.com/jbonofre/karaf-boot
> It's a mix of rewrapping of existing code (from aries, pax-exam, etc) and
> additions.
> I created the annotations, I'm now working on the karaf-boot-maven-plugin
> based on Christian's work in aries (I'm actually scanning the boot
> annotations now, and generating the XML).
> I will push new changes later today and tomorrow.
>  Open Questions
>  ---------------
> * For now, I would prefer to be 'artifacts' and 'resources' generator: I
> think it's better than to depend to a feature running in Karaf, but it's
> open to discussion.
> * I'm now generating blueprint. Probably native OSGi or scr generation can
> make sense.
> * I'm generating bundles: thanks to the Karaf4 features resolver, as the
> bundles provide requirements/capabilities metadata, I think it's a good
> start. However, maybe it's worth to be able to create features, kar,
> profile.
> Thoughts ?
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

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