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:39:50 GMT
For me, one of my small concern about Spring-Roo is that you still need 
to use the CLI. But it's a step forward to easily setup project.
I'm trying to do something more "straight forward" in karaf-boot: focus 
on your code, use the karaf-boot annotations, just inherit from the 
karaf-boot-parent: we do the rest.

Anyway, I will add sketching of karaf-roo ;)

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 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