karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milen Dyankov <milendyan...@gmail.com>
Subject Re: [DISCUSSION] Karaf Boot
Date Thu, 10 Sep 2015 15:58:51 GMT
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
>>>>
>>>>
>>>
>>
>


-- 
http://about.me/milen

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