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 17:16:33 GMT
So correct me if I'm wrong but if I get the sample you provided in the
first mail and replace:
 - the parent pom with "maven-bundle-plugin"
 - @Bean with @Component
 - @Init with @Activate

wouldn't that have the exact same end result? I mean it obviously differ in
terms of what gets generated (Blueprint vs DS) but form end user
perspective there is no difference, right?




On Thu, Sep 10, 2015 at 6:55 PM, Jean-Baptiste Onofré <jb@nanthrax.net>
wrote:

> Hey Milen,
>
> Actually, there's too part:
> 1/ karaf-boot-starter will do the ready to start artifact, embedding
> karaf, but it's another point
> 2/ the value of karaf-boot annotations and plugin is first to simplify the
> bundle/artifact ready to be deploy-able into Karaf (generate the "plumbing"
> easily for developers).
>
> Regards
> JB
>
>
> On 09/10/2015 06:50 PM, Milen Dyankov wrote:
>
>> " ... that you deploy in Karaf ..."
>>
>> OK may be I misunderstood the concept. I thought the result is standalone
>> executable JAR, thus my comments above. If on the other hand I need to
>> install Karaf and then deploy my services into it I really don't see how
>> it
>> differs form what people are doing now?
>>
>> I'm sorry if I'm not making much sense. I didn't have the time to
>> experiment with your code and samples so may be I'm missing an important
>> peace here.
>>
>> Best,
>> Milen
>>
>>
>> On Thu, Sep 10, 2015 at 6:27 PM, Jean-Baptiste Onofré <jb@nanthrax.net>
>> wrote:
>>
>> Allow me to disagree: Karaf is a perfect container for microservices.
>>>
>>> Image to create a microservice (using karaf-boot) that you deploy in
>>> Karaf
>>> and use such service in another microservice, all wired with OSGi service
>>> and Karaf: we leverage OSGi/Karaf as a microservices container.
>>>
>>> But even without talking of microservices, new developers to Karaf (and
>>> OSGi generally speaking) are frustrated by the effort on non business
>>> code
>>> to do (I have to write an Activator, or a descriptor, etc, etc).
>>> So, a tooling to simplify this is still a valid addition IMHO.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 09/10/2015 06:23 PM, Milen Dyankov wrote:
>>>
>>> I might be wrong but I think the whole success of SpringBoot (apart from
>>>> having the "Spring" in it) is the microservices hype!
>>>> it's quick and easy but most usecases follow the "create one (or very
>>>> few)
>>>> service(s), pack them as single executable and access them via REST"
>>>> pattern. We can obviously do the same with OSGi and Karaf in particular
>>>> but
>>>> personally I think this makes absolutely no sense. In such approach one
>>>> in
>>>> not benefiting form OSGi almost at all. Honestly speaking I would argue
>>>> that if one does not understand how OSGi service layer works (regardless
>>>> of
>>>> the framework used to register/access services) it makes no sense to use
>>>> OSGi at all.
>>>>
>>>> Just my 2 cents!
>>>>
>>>> Regards,
>>>> Milen
>>>>
>>>> On Thu, Sep 10, 2015 at 6:08 PM, Christian Schneider <
>>>> chris@die-schneider.net> 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
>>>
>>>
>>
>>
>>
> --
> 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