Hi JB, my point is that you are a veteran on different technologies, that you know > ;) >
and that's the reason I already know where other people are struggling with. I do a lot of consulting to people that either don't care or are not interested in their day-job. They just need to get that stuff done. Therefore it needs to be easy as taking a dump. > > But anyway, veteran or not, it would be very helpful to have tooling. I > would love to have a karaf-boot tool that allows me to quickly create my > artifacts, without taking a look on 3 or 4 different projects/technologies, > plugins, etc/ > > Just my €0.02 (I'm in € now ;)). > > I'm with you that we need better tooling, but actually we should focus on the build-chain first. Make it good, make it awesome. After that let's take a look on where we find some more room for improvement. That's why I think if we talk of *-boot we should focus on having easy inclusion of different dependencies. Cause not everybody want's to start with a REST-Microservice, but might be interested in Database first. That's why we need different BOMs that stick together as lego-bricks. regards, Achim > Regards > JB > > > On 09/11/2015 08:47 AM, Achim Nierbeck wrote: > >> Hi JB, >> >> I'm very sorry but I have to completely disagree on this. >> Let me point this out inline >> >> >> Generally speaking, I think we are not the best ones to evaluate this >>> because we are involved in the "low level", and so we might not see >>> values >>> there. >>> >>> >>> This might be true for core developers that only work on Karaf, it >> certainly doesn't affect me, as my day-job requires me to work with >> everything else but OSGi. Therefore I think I'm in the very convenient >> position to say: "I know what is missing and I know where the benefits of >> Spring-Boot are" >> Working on Karaf and Pax Web is just a mere hobby for me, as it doesn't >> pay >> my bills. >> >> >> It would be great to have "new developers" feedback (it's where I started >>> for karaf-boot actually). That's the key point: think when you are very >>> new >>> to Karaf and you have to start. >>> >>> >>> see above >> >> >> Anyway, my comments inline: >>> >>> >>> On 09/10/2015 11:58 PM, Achim Nierbeck wrote: >>> >>> 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. >>>> >>>> >>> I agree. With the current annotations (whatever the ones we use, CDI, DS, >>> etc): >>> - they are very low level, and doesn't provide "key turn" annotations >>> - they don't provide enterprise ready annotations >>> - depending of the annotations, it's spread on different dependencies and >>> packages (not easy for the user) >>> >>> Basically, a new developer starts on Karaf, it could be lost: a fair >>> question is what technology should I use. >>> >>> >>> Use CDI it's a standard annotation and can equally be used for Spring or >> in >> a modern Enterprise Server. >> >> >> >> We bring an important flexibility, which is awesome for the advanced >>> users. >>> >>> But this flexibility means it's not easy to start and choose something: I >>> have to learn, prepare my pom.xml accordingly, etc. >>> >>> The purpose of karaf-boot is not to create new technology, it's just to >>> leverage the existing ones, hide it to the developer, and provide a quick >>> and easy starter. >>> >>> >>> >> great, and this is the point we need to focus on! Make it easier to >> develop >> a Bundle to run on Karaf. >> That's why I might need to elaborate a bit more about my idea of BOMs. >> Take for example the spring-boot-log4j-starter bom. If you use that one >> all >> is included to work with log4j logging, one dependency in your POM, >> no need to have a Parent. >> Same for REST, depending on what people would like to use it can be a >> karaf-boot-cxf-jaxrs-starter bom, which contains the dependencies for >> working with cxf rest including the feature definition that needs to be >> used by karaf. >> Here we need something "new", if a feature is present in the POM and we >> have the karaf-maven-plugin in use (the only valid point for a Parent POM >> to have that as default available) this feature must be used inside the >> generated feature as dependency and the karaf-maven-plugin should generate >> according to the requirements the dependencies from that feature. >> >> >> >>> >>>> 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. >>>> >>>> >>> I already have karaf:run on one of my branches, but the purpose is >>> different. Let's keep the starter out of the picture for now. >>> >>> A BoM can be materialize as a parent-pom, it's the purpose of the >>> karaf-boot-parent. >>> >>> Maven archetype is good, but it's require to execute the archetype, >>> update >>> the project definition before being able to build. Of course, it makes >>> sense to provide it. >>> >>> But, the big advantage of karaf-boot-parent, it's again easy and key >>> turn: >>> I'm a new developer, I just inherit from karaf-boot-parent, I just define >>> groupId, artifactId, version, I'm ready to go. >>> >> >> >> I'm sorry but this is a too big cannon you use to shoot on sparrows. >> Think minimalistic and modular. With the karaf-boot-*-starter boms we >> would >> achieve something far more modular and closer to what people actually >> need. >> And forgive me for comparing it with spring-boot again, the big benefit of >> it is actually those *starter boms. >> >> >> >>> >>> >>> >>>> 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. >>>> >>>> >>> It's another point, but @rest and karaf-boot-starter address this, using >>> profiles and karaf minimal distribution. >>> >> >> >> here we are inline, a minimalistic distribution based on profiles should >> do. >> >> >> >>> >>> >>> >>>> 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. >>>> >>>> >>> See my previous comment. >>> >>> >>> >>>> >>>> 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 >>>> >>>> >>> You talk about JPA/JTA and I agree. But don't forget high level >>> annotations like @jpa(provider = "openjpa", dataSource = "my"), @rest, >>> @soap, @jms, etc. >>> >>> >> all those "high" level annotations are already solve. >> Take Jersey or CXF you can use either to solve the @rest or @soap >> annotations. We don't need extras here >> We should thoroughly look through the ones that are already available with >> CDI and make sure we don't re-invent the wheel wrong here. >> >> >> >>> That's why abstract, high level annotations could make sense. >>> >>> >> >> only for the ones missing, yes then it might be helpful, but to my >> understanding this should be the last Story in the backlog to have a >> quick-and-easy to build environment. >> >> >> regards, Achim >> >> >> >> >> >>> Regards >>> JB >>> >>> >>> >>> >>>> 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 >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>> 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
