I've just built a small armada of DS services in Karaf. I didn't find it too terrible (except for learning DS at all).
A typical service is one bundle + its dependencies. So, for each one, I make a Maven module that is of <packaging/> bundle, and then I add an execution of the feature generator. I use DS annotations to use and register services. If I had SCR>1.8.2, I'd be using .cfg files to do cardinality constraints. Now, I'm not interested in JPA and JTA, so I don't have exposure to whatever problems those pose. I could imagine another lifecycle in the karaf-maven-plugin that would combine the bundle-ing and the feature-ing. I hit some aspects of the feature generator that bothered me. But I didn't see any problems that correspond to a reason to want to use any new annotations. On Thu, Sep 10, 2015 at 1:44 PM, Jean-Baptiste Onofré <[email protected]> wrote: > I fully agree: my concern about SCR is: > 1/ it's very OSGi oriented and low level > 2/ it's not extendable easily > > That's why I would prefer to abstract with a new top annotations (providing > advanced high level features like security, jpa, etc). > > Regards > JB > > > On 09/10/2015 07:33 PM, Christian Schneider wrote: >> >> Providing jpa and jta annotations for SCR would be great. I think the >> big problem with scr is that it does not have a plugin model. >> So while it might be possible to add jpa / jta processing around the >> service it might be difficult to provide it in a way that it can be >> combined with other annotations >> from different sources. Like e.g. security. Unfortunately Peter Kriens >> was not very open when I asked him about such a model. Do you have an >> idea how to make it work? >> >> Another question of course would be where to put that code. >> I would tend to put such code maybe in felix near the scr impl and the >> maven bundle plugin as it is quite related. >> >> Christian >> >> Am 10.09.2015 um 19:22 schrieb Jean-Baptiste Onofré: >>> >>> 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
