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:40:49 GMT
I am fully positive on a prototype. Especially as it allows to discuss 
on a final design. Be careful though with a release as people then 
quickly start to build production code from it.


Am 10.09.2015 um 18:32 schrieb Jean-Baptiste Onofré:
> I got your point.
> The reason why I started from new abstract/high level annotations that 
> create blueprint is because the features set is interesting.
> It's just a proto, so I would like to complete it, just to illustrate 
> how it would be easier to a developer to start with karaf-boot.
> My only motivation: central point, easy to use to create "key turn" 
> artifacts.
> Spring ROO approach is indeed interesting. I will try to sketch 
> something on phase 2 of the proto.
> Regards
> JB
> On 09/10/2015 06:27 PM, Christian Schneider wrote:
>> 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
>>>>>>> One of the purpose of karaf-boot annotations is to "abstract"
>>>>>>> actual code/artifact that we generate. So, if now we generate
>>>>>>> blueprint, without changing the karaf-boot annotations, we will
>>>>>>> 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
>>>>>>> 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
>>>>>>>> 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
>>>>>>>> too
>>>>>>>> much
>>>>>>>> for now.
>>>>>>>> I agree with the idea of using a BOM instead of a parent
>>>>>>>> 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
>>>>>>>>> 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,
>>>>>>>>> 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
>>>>>>>>> container, and deploy those artifacts there. Even if
>>>>>>>>> "container"
>>>>>>>>> approach is the most important for me, we can give even
>>>>>>>>> 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
>>>>>>>>> just
>>>>>>>>> inherit: that's all ! All plugins, dependencies, etc
>>>>>>>>> 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
>>>>>>>>> that you
>>>>>>>>> use directly in your business code (like @Bean, @Service,
>>>>>>>>> @Reference,
>>>>>>>>> @Inject, etc): again, your focus on your code, karaf-boot
>>>>>>>>> with
>>>>>>>>> the
>>>>>>>>> plumbing.
>>>>>>>>> * karaf-boot-maven-plugin (coming with karaf-boot-parent)
>>>>>>>>> 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"
>>>>>>>>> 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.
>>>>>>>>> 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,
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> it's a
>>>>>>>>> good
>>>>>>>>> start. However, maybe it's worth to be able to create
>>>>>>>>> kar,
>>>>>>>>> profile.
>>>>>>>>> Thoughts ?
>>>>>>>>> Thanks,
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>> -- 
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com

View raw message