" ... 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é <[email protected]> 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 < >> [email protected]> 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é <[email protected]>: >>>>>>> >>>>>>> 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é >>>>>>>> [email protected] >>>>>>>> http://blog.nanthrax.net >>>>>>>> Talend - http://www.talend.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > -- http://about.me/milen
