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 17:26:57 GMT
But yes, I will add a sample-simple-scr as it's also supported by 
karaf-boot.

My point is the scr annotations are not enough for ready to use use 
cases (think about @rest, @jpa, @jta, @soap, @jms, etc annotations that 
we should provide).

Regards
JB

On 09/10/2015 07:16 PM, Milen Dyankov wrote:
> 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
>>
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message