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 Fri, 11 Sep 2015 06:14:15 GMT
I agree with Scott that OSGi Remote Services is a good solution to 
publishing the Rest services. It also allows to consume Rest services in 
a similarly easy way.
For the spring boot like setup it makes sense to use a very ligth weight 
rest support by default.

We can also write an extender that scans annoations and publishes the 
rest services. It could be done a little bit smaller than ECF but I am 
not sure if the effort is worth it.

Christian

Am 11.09.2015 um 00:40 schrieb Scott Lewis:
> On 9/10/2015 2:58 PM, Achim Nierbeck wrote:
>> <stuff deleted>
>> The microservice dance
>>
>> actually it's just add a rest-service on top of a OSGi service, 
>> that's all
>> that is needed in Karaf.
>> Right now I'm not in favor of any certain framework. CXF seems a bit
>> bloated but is known to work, but requires blueprint.
>> Jersey, I've seen that to be working with "plain" OSGi. A bit of 
>> polishing
>> and it should be quite easy to use, especially with CDI at hand.
>
> I would suggest the use of OSGi Remote Services/RSA [1].   The Remote 
> Services spec defines standard service properties triggering the 
> export of the service via some unspecified distribution 
> system/transport...typically in response to service registration done 
> through whatever means...e.g. DS, java code, Dependency Manager, 
> Spring, or anything else that uses the service registry. One of the 
> standardized properties allows a distribution provider to be selected, 
> separately for each service instance if needed.
>
> Each distribution provider can be as small or large as required for 
> the use case.  For example, ECF's RSA impl now supports using CXF, 
> Jersey, or other Jax-RS implementations along with Hazelcast, rosgi, 
> tcp, JMS, MQTT, and other providers [2].   Or if you need to you can 
> create and use your own distribution provider.  In any case, the 
> service won't be bound to any distribution provider or RSA impl on 
> server or clients, and can be changed prior to service registration.
>
> Scott
>
> [1] http://www.osgi.org/Specifications/HomePage
> [2] 
> https://wiki.eclipse.org/Tutorial:_Using_REST_and_OSGi_Standards_for_Micro_Services
> https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service 
>
>
>
>
>>
>> But it needs more to dance the microservice dance, you need "small"
>> containers ... which is quite contrary to the way Karaf and OSGi in 
>> general
>> is working with services.
>> But this is the point I think the karaf profiles come in handy. You 
>> don't
>> need a full blown Karaf, just a basic infrastructure with your own 
>> Bundle,
>> might as well ignore the shell. In the end dump that into a docker
>> container and if you need to do a bugfix do it the "docker" - way.
>>
>>
>> spring-boot brings it all in one go
>>
>> karaf-boot should do the same, but actually I fear we do more then 
>> needed.
>> For a new Project setup I'd rather would like to see different
>> karaf-starter-* BOMs and a karaf:run maven plugin
>> Some more docuementation for the profiles of Karaf could also be 
>> helpful :D
>> to build minimalistic karaf instances runnable in docker containers.
>> Regarding the karaf:run it might be interesting to "re-activate" the
>> pax:run maven plugin to run nicely with a karaf instance, or use it as
>> foundation for the karaf:run maven plugin.
>>
>>
>>
>> So in the end, do we really need all this?
>> I'm not so sure, but we surely need an easier "to use" approach.
>> Therefore we should first focus on having easier setup of bundle
>> development.
>> -> karaf-boot-starter-* BOMs should take care of that
>> -> karaf:run should make it easier to have a running container
>>
>> Do we need new annotations? I can't see that yet.
>> Instead we should/could focus on the following:
>> a) make sure DS also is capable to work with JPA/JTA and some other
>> enterprise annotations
>> b) make sure CDI works with runtime JPA/JTA annotation smoothly
>> c) provide more demos and archetypes with OSGi and CDI annotations
>>
>>
>> regards, Achim
>>
>>
>>
>>
>>
>> 2015-09-10 20:41 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>>
>>> Thanks Milen,
>>>
>>> it's an open place to discussion. We just share standpoints and 
>>> opinions:
>>> that's the key part !!!
>>>
>>> My goal is to give more traction on Karaf by providing easier
>>>
>>> We all provide valid points, but I think we are not the most setted to
>>> argue as we are deeply involved in OSGi and Karaf. The karaf-boot proto
>>> came when discussing with new Karaf users, coming from "outside" of 
>>> OSGi,
>>> or people that decided to use spring-boot (even if they like a lot 
>>> Karaf),
>>> just because it's easier. It's hardly frustrating for us as we just 
>>> need
>>> some tooling to provide even more traction. On the container side, I 
>>> think
>>> Karaf is already great, and answers all needs. The part where we should
>>> improve what we deliver is around developer tooling: easier, faster, 
>>> key
>>> turn.
>>>
>>> If karaf-boot will be a success, I don't know (who knows ? ;)). But
>>> anyway, it brings points, questions, and identify some missings in the
>>> current picture.
>>>
>>> My $0.01 ;)
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 09/10/2015 08:02 PM, Milen Dyankov wrote:
>>>
>>>> Well I was just referring to your example but I get your point. Which
>>>> reminds me of EnRoute <http://enroute.osgi.org/> project which despite
>>>> the
>>>> big names and the most popular OSGI build tool behind it, doesn't 
>>>> seem to
>>>> get as much traction as I expected!
>>>>
>>>> That said, I really admire your enthusiasm and wish KarafBoot can 
>>>> be more
>>>> successful that that. I'm not trying to discourage you! Just it 
>>>> seams what
>>>> you are after is something that other people have tried already with
>>>> questionable success.
>>>>
>>>> Best,
>>>> Milen
>>>>
>>>>
>>>>
>>>> On Thu, Sep 10, 2015 at 7:22 PM, Jean-Baptiste Onofré 
>>>> <jb@nanthrax.net>
>>>> wrote:
>>>>
>>>> And how to you deal with jpa, jta, rest, etc with SCR annotations ?
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>> -- 
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>


Mime
View raw message