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:15:21 GMT
So, let me ask just a question: do you think, right now, it's easy and 
quick to create a bundle ready to use with CDI annotation for instance 
(dealing with the dependencies, etc) ? Moreover, you make a point: which 
annotations would you chose ? CDI, SCR, JEE, ?

Think the project not as a big one, but a collection of small projects 
(like in microservice).

If we don't provide tooling like karaf-boot, without knowing the 
details, new developers will go to spring-boot: and it's exactly what 
spring-boot does: they rewrap annotations (on a higher level), 
leveraging other annotations and technologies.

Regards
JB

On 09/10/2015 06:08 PM, Christian Schneider wrote:
> I already created such a maven plugin in aries. The user can use
> standard CDI and JEE annotations and the result is blueprint xml.
> How is the new approach different / better?
>
> Why should it be good for the developer to move away from well defined
> standard annotations and use custom annotations that bind him to karaf?
> I mean if this is created by the spring guys I know they want to catch
> people by perceived simplicity and then make sure to make it difficult
> to switch. As an open source comminity I do not know why we should do
> something like this.
> Abstracting away from frameworks just means you create another layer
> that people then also have to learn. There were some cases in the past
> where this make sense because the underlying frameworks sucked (like JEE
> 2). This is not the case today though I think.
>
> What kind of use case do you have in mind? Every project starts small
> but it needs to be able to grow then. You can not start with custom
> annoations and then tell people to later switch to something else when the
> project grows. I think it makes more sense to make it easier for people
> to use the standard annoations and use the right dependencies.
>
> If we simply provide a tooling that makes it easy to start with SCR or
> blueprint we provide much more value for people as thery can then grow
> without any breaking changes.
>
> Christian
>
> Am 10.09.2015 um 17:46 schrieb Jean-Baptiste Onofré:
>> Because all these annotations are runtime: here we talk about tooling
>> at build time.
>>
>> More over, the purpose is to provide more high level annotations,
>> which abstract actual annotations/frameworks that we can use under hood.
>>
>> The purpose of centralizing all in karaf-boot is to have a central
>> project: the developer just use karaf-boot, it doesn't really know
>> what technologies are involved behind the scene.
>>
>> For instance, in spring-boot, they use activemq, jersey, etc, but all
>> from spring-boot. The developers don't know a rest service use jersey
>> for instance, it's completely abstracted.
>>
>> Again the purpose is to simplify life for developers: splitting the
>> annotations in different projects introduces complexity (at least to
>> find the dependencies and core import packages).
>>
>> If an advanced developer wants to use CDI, SCR, etc, he can of course.
>>
>> Regards
>> JB
>>
>> 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