karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [DISCUSSION] Karaf Boot
Date Fri, 11 Sep 2015 06:51:00 GMT
Sorry,

but for me this is to "put the cart before the horse".
We should work more on the infrastructural points and after that get to the
point and do
invent "new" annotations that are needed for buildtime stuff ...
... I'm sure there are already some tools available to build jpa
persistent.xmls from annotations
There are bunch of tools out there we don't need an extra one.

But we do need to make it easier to have an ready to use Bundle, and this
is where the *-starter boms come in handy.
After that we might be able to decide to add extra annotations for
generation of blueprint.xml or other infrastructural components.

regards, Achim


2015-09-11 8:36 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

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



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message