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 16:05:23 GMT
Hi Milen,

The target is developers, first without any OSGi or Karaf background, 
that want to develop application to run on Karaf.

karaf-boot is an name, but it could be name "osgi-boot".

Actually, it's not to compete with spring-boot.

I asked to spring-boot developers the arguments why to use spring-boot 
rather than Karaf or OSGi.
Interestingly, the first answer is not to the bootstrap, it's because 
it's simply to develop. They just say: "Karaf is awesome, but I need to 
much effort to create an artifact, I spend more time on pom.xml, 
blueprint XML, or OSGi Activator, more than on my actual code".

So, the purpose of karaf-boot is to provide a tool to easily develop 
Karaf/OSGi artifacts.
It can be useful for experienced Karaf/OSGi developers, as it can avoid 
them to create lot of code or descriptors.

Regards
JB

On 09/10/2015 05:58 PM, Milen Dyankov wrote:
> Guys,
>
> I'm following this discussion and jumping back and forth between "I'm
> totally lost" and "oh I get it"!
>
> I get all the tech part, all the maven, annotations, 3rd party
> technologies, Blueprint vs. DS vs.  ... and all other tech concerns.
> What I don't get is the business / purpose part. Who is the target group of
> Karaf Boot ? Is it Karaf users/developers? Is it OSGI developers? Is it
> Java developers in general?
> Is it just a coincidence/buzzword/..., or there is an attempt to compete
> with SpringBoot? If so, what I think we need is rather "OSGIBoot" if you
> know what I mean.
>
> Regardless of how it will work I would be more interested how you envision
> the usage of it! In another words, consider the 3 cases:
>   (a) experienced with Karaf
>   (b) experienced with OSGI but not Karaf
>   (c) experienced Java SE / EE developer with no OGSi knowledge
>
> How would you try to convince a typical representative of those that they
> should try Karaf Boot ?
>
> Best,
> Milen
>
>
>
>
> On Thu, Sep 10, 2015 at 5:40 PM, Christian Schneider <
> chris@die-schneider.net> 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