karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSSION] Karaf Boot
Date Thu, 10 Sep 2015 16:27:39 GMT
We fully agree that the current effort to set up an enterprise project 
is too big. We also agree that we need to cover the people that 
currently try out spring boot and provide something that is similarly 
easy to start with.

So I think we need to look into how to make this easier. Rewrapping 
annotations is the solution of spring boot and they have their 
motiviation to do this. I really doubt that all of this motiviations 
benefits the users.
So while I think it makes sense to pick some good ideas from spring boot 
I think we should not blindly do the same just to compete. The part of 
spring boot that I like is the creation of the self contained artifact.

Which annotations to use depends on the framework you use. CDI/JEE is 
supported by the maven blueprint plugin or pax-cdi. The DS annoations 
are supported by SCR. It would not make sense to mix them in one bundle. 
So I think we need to provide tooling to create each of the three sets.
Of course we can start with only one of these. I think the approach of 
spring roo would make a lot of sense for us. Have a shell that allows to 
add functionality to a project. The reason why I would choose this is 
that the end result is fully standards based and can then also work 
without the setup tooling.

Christian

Am 10.09.2015 um 18:15 schrieb Jean-Baptiste Onofré:
> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


Mime
View raw message