karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSSION] Karaf Boot
Date Thu, 10 Sep 2015 14:53:18 GMT
Hi Guillaume,

thanks for your feedback.

I fully agree about providing more high level annotations (it's what I 
do with @jpa, @rest, @soap, @jta annotations).

I agree that the current annotations are too low level, and blueprint 
"oriented". I just move forward a bit with the current codebase, just to 
illustrate karaf-boot usage in the samples.

But again, you are right, and I will create a new annotations set.

One of the purpose of karaf-boot annotations is to "abstract" the actual 
code/artifact that we generate. So, if now we generate blueprint, 
without changing the karaf-boot annotations, we will be able to generate 
something else (why not SCR, etc).

I agree with a BOM, but I think it's interesting to provide both:
- providing a ready to use parent pom allows developers to create a very 
simple pom.xml where all plugins and dependencies are already defined
- for more advanced devs, they can create their own pom.xml starting 
from the BOM or archetype.

Thanks again for your feedback !


On 09/10/2015 04:44 PM, Guillaume Nodet wrote:
> 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
> change.
> 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

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message