Hi Christian, comments inline.
regards, Achim 2015-09-11 9:26 GMT+02:00 Christian Schneider <[email protected]>: > Hi Achim, > > very good overview of the problems users face and I also agree with your > proposed solutions. > Just for pax cdi I think we are not yet there so I would go with blueprint > generation from CDI annotations for now and switch to > proper pax cdi when it is fully working. > > absolutely, therefore my proposal to improve what we have. > On top I would add that I have the feeling that springsource more or less > hyped microservices because they know spring does not scale! > > The bigger a spring application grows the more you see that it does not > provide real modularization. > 1. All of the dependencies have to be hammered into a flat classpath. This > works or an astonishingly long time but at some point > in the growth of a project it gets harder and harder. > 2. The single spring context. In the end the whole application runs on one > merged spring contex. All the settings done in the small > contexts scattered around the project artifacts have to work together in > the big context created at runtime. > 3. No enforcement of visibility rules. You can define an API but you also > have access to all the impls and developers tend to use them > when the time pressure comes. > 4. Static setup. Spring has to boot up all beans in the correct order. > 5. They tried with OSGi but I think they realized that making spring fully > OSGi ready is too much work > > full ack, that's my critique of spring since years. > All this leads to people thinking that an application needs to be split > into microservices to make the above problems smaller. > Only later they find that implementing microservices is pretty hard. The > biggest problem is that they may not share a database. So you have > to invent a lot of additonal logic to keep the different databases in the > same state. Additionally there is security and monitoring which is > also pretty much unsolved in microservices. > > If you compare this to a proper OSGi application then the need for the > spring style microservices is almost not there. Instead you write small > modules with a clearly defined API and boundaries and OSGi services to > communicate. If you need to cross server boundaries then OSGi remote > services allow > to extend the OSGi services model to a larger environment. > > you'll see that in my talk at apache-con :D > So I would argue that the microservices hype will not live to its > promises. People will realize that OSGi provides better solutions with less > overhead than microservices. > This will take some time of course and we will need to make sure to not > loose too many people to spring boot in the mean time. > > So what we need is a nice way to create microservices in karaf like you > described. Additionally we should also allow people to just deploy a normal > OSGi > application in a simple way like you would for a microservice. So I think > we need to make sure that karaf boot not only works for single projects but > also > for whole applications in form of a set of bundles. This will allow people > to transition away from pure microservices when they realize they are not > as good as they think > while still keeping a lot of the benefits of the small and simple > deployment unit. > > yep, that's my intention and thanks for the feedback. > Christian > > > Am 10.09.2015 um 23:58 schrieb Achim Nierbeck: > >> Hi >> >> after reading this thread about two times, I finally understood the >> intention and the confusion in the thread. >> Let me try to summarize this to start some more confusion :-D >> >> Initial Problem: >> - learning OSGi has a steep learning curve >> - initial setup for a new OSGi project needs a lot of infrastructural >> "thingis" >> - doing the "microservice" dance is hard as it requires to much "extras" >> to >> have a simple REST service >> -- including infrastructure >> - Spring boot brings everything needed in one place in one "application" >> with just annotations >> >> These are the "problems" we know of and if I did get it right are the >> intention for the Karaf-Boot project. >> Now let me try to summarize the idea on how to solve that. >> >> From a simple Class file with some annotation generate >> - a OSGi service, including OSGi wiring via Blueprint - via an extra maven >> plugin >> - get rid of all those infrastructural "add-ons" for the first OSGi bundle >> by having a easy to use Parent-POM >> - do the microservice - dance by wrapping everything together including >> CXF >> in a "one-size-fits-all" executable jar, which is a wonna-be-spring-boot >> jar but made of karaf >> >> Now some thoughts of mine ... >> I somehow fear you try to mix several problems and try to solve all of >> them >> with one go. >> Let's try to analyze those initial problems separately and we might find a >> valid approach. >> >> Learning curve of OSGi: >> right now we have different approaches to make it easier with OSGi. >> - Blueprint >> - DS >> - CDI >> - iPojo >> - Felix DependencyManager >> >> Blueprint just tastes to much like spring xml and actually isn't state of >> the art anymore. You'll get a lot of negative feedback regarding the >> "old-school" xml. It's biggest plus is the Enterprise "features" like JPA >> and JTA, which isn't covered by any other technique right now (unless you >> look at non Apache Hosted OSS projects like Amdatu). >> >> Declarative Services, especially the latest R6 looks rather promising, >> especially in conjunction with MetaType. But we have specialized >> annotations which again don't actually help with the learning curve. >> Another downside is the missing JPA and JTA Enterprise features. >> >> CDI, we have the Pax-CDI project which has been on the way of being the >> reference implementation of the OSGi-CDI spec. Well, we all know how that >> turned out. One of its biggest benefits is definitely the easy transition >> because of the CDI annotation which help a lot with wiring inside a bundle >> and also with extra annotations (@OsgiService) with OSGi-Services. CDI >> though still lacks runtime OSGi annotation support for JPA and JTA if we >> are somehow capable to compensate that, we'll have the required EE stack >> at >> hand. >> >> iPojo ... sorry never used >> >> Dependency Manager is a bit more low-level compared to DS but seems to >> have >> a nice DSL for easy wiring of Services. >> >> So do we really need another Build-Time-Annotation which generates another >> "wiring" plan which is used during runtime (exactly what DS already does)? >> Right now I'm not convinced of this. Instead of another generation I would >> prefer to use CDI as it is known to work in classic Spring/EE world and >> OSGi. Instead we should focus on bringing the full support of Enterprise >> style annotations to the OSGi world. >> >> >> Initial Setup for a new OSGi Bundle Project >> >> Instead of a parent POM I think it would be much more beneficial to work >> with a BOM (Bill of Material) for easier development, especially when >> working with std. CDI annotations plus some extra PAX-CDI ones. Maven >> Archetype are actually good enough to create an initial structure for a >> maven project. >> The big benefit of the spring-boot approach is to actually have a bunch of >> different BOMs that can be used to add certain functionalities to the >> project, aka spring-boot-*-starter. >> To start a karaf-boot I think we should first try to have a karaf:run >> available as maven plugin. >> >> >> 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. >> >> 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é <[email protected]>: >> >> 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é <[email protected]> >>>> 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é < >>>>>> [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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> >>>>> 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 >>> >>> >> >> > -- 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
