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 15:46:39 GMT
By the way, we don't duplicate functionality: we just leverage and 
generate the resources.

On 09/10/2015 05:40 PM, Christian Schneider wrote:
> I am not really enthusiastic about duplicating functionality of cxf or
> aries. Aries supports a very nice approach for injections, jpa and jta.
> Why should it make sense to recreate that?
> Aries blueprint also has annoation support even in two flavors (CDI,
> custom). How does the new approach interact with this?
>
> Instead I propose we create support for such annotations in the
> respective projects (where they are missing) and concentrate on karaf as
> a container not an application development framework.
> By leveraging the existing frameworks we profit from their own
> development teams. Whatever we recreate will have to be developed by the
> very few resources of the karaf team.
>
> Christian
>
> Am 10.09.2015 um 16:53 schrieb Jean-Baptiste Onofré:
>> 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 !
>>
>> Regards
>> JB
>>
>> 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message