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 Fri, 11 Sep 2015 06:36:21 GMT
+1,

what we should provide is something like @rest annotation that does all 
for the developers. So, this annotation can leverage ECF or something 
else, it's not a problem: the purpose of karaf-boot is to hide technical 
complexity to the developer and allow him to focus on his business code.

Regards
JB

On 09/11/2015 08:14 AM, Christian Schneider wrote:
> 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
>>>>
>>>
>>>
>>
>

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

Mime
View raw message