Guys, I'm following this discussion and jumping back and forth between "I'm totally lost" and "oh I get it"!
I get all the tech part, all the maven, annotations, 3rd party technologies, Blueprint vs. DS vs. ... and all other tech concerns. What I don't get is the business / purpose part. Who is the target group of Karaf Boot ? Is it Karaf users/developers? Is it OSGI developers? Is it Java developers in general? Is it just a coincidence/buzzword/..., or there is an attempt to compete with SpringBoot? If so, what I think we need is rather "OSGIBoot" if you know what I mean. Regardless of how it will work I would be more interested how you envision the usage of it! In another words, consider the 3 cases: (a) experienced with Karaf (b) experienced with OSGI but not Karaf (c) experienced Java SE / EE developer with no OGSi knowledge How would you try to convince a typical representative of those that they should try Karaf Boot ? Best, Milen On Thu, Sep 10, 2015 at 5:40 PM, Christian Schneider < [email protected]> 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 >>>> >>>> >>> >> > -- http://about.me/milen
