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