James, I don't think JB cared. He was probably more than happy to have a discussion than to have to simply walk through slides without any feedback. At least that's how I prefer it.
Personally I think that OSGi is really a great way to make sure that people get into the good practice about thinking about the full lifecycle of code, not just developing it and starting it, but also shutting it down, and what happens when dependencies are not present or shutdown. In that regard I've seen that in our team since we switched to OSGi, although it took a little investment in terms of getting used to it, people are a lot more productive because they can focus on the module they are building without having to restart the whole container. This is a huge improvement over Docker type of deployments where rebuilding and restarting a container can take a lot longer to test a single change. I believe that OSGi is also more than proven since it has been around for a long time, and it is defined by a standard body that is quite significant. I just wish it would get adopted more, and hopefully Karaf will help with this effort. Not to make me say that Docker or Spring Boot or the Play Framework don't have their merits, but I think that it is not enough to look at the time to get started, it is also important to look at the TMDT (an acronym I just made up : Total Maintenance and Deployment Time :)). cheers, Serge... - -- --- -----=[ shuber at jahia dot com ]=---- --- -- - CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227 Acacias, Switzerland twitter: @sergehuber <https://twitter.com/sergehuber> <http://jahiaone.com/register> JahiaOne <http://www.jahiaone.com/>, our international user conference is back! June 10-12 in Paris - Grab your tickets now <http://www.jahiaone.com/> ! Jahia is a leading open source User eXperience Platform (UXP) vendor, relentlessly working at transforming a siloed industry into a user-driven one, beyond technology constraints - http://www.jahia.com On Sat, Apr 18, 2015 at 10:47 AM, James Carman <ja...@carmanconsulting.com> wrote: > Serge, > > We had some pretty good discussions during JB's talk (hope we didn't > hijack it too much, JB). I don't think this topic really has anything to > do with Docker, necessarily. Docker is merely a tool people employ to > implement a deployment strategy. I think it basically boils down to the > notion that in the "cloud era", it's simpler and cheaper to spin up a new > node configured the way you want. Cloud-enabled applications need to be > "cloneable" in this way already, so you kind of get this benefit for free. > > This doesn't mean we can't use OSGi to piece together these nodes. OSGi > isn't only about being able to runtime-refresh your modules. There are > many other benefits of the OSGi programming model that make it suitable for > building statically-configured applications as well. > > Just my $0.02 > > James > > On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <shu...@jahia.com> wrote: > >> Interesting discussion indeed. >> >> I'm currently at ApacheCon US and I've taken a few opportunities to >> promote Apache Karaf which surprisingly few people know about. But again >> what I was describing earlier is really a frequent feedback : is modularity >> worth the trouble when I can built "micro-services" that are actually >> running in docker containers ? Although I am convinced that the two are not >> in opposition, I think it would be great to have a killer use case to >> demonstrate what the benefits of using Karaf would be. >> >> I'm really looking forward to meeting Jean-Baptiste in person ! I love >> Karaf and I hope to be able to exchange with him a few experiences around >> it. >> >> Regards, >> Serge >> >> - -- --- -----=[ shuber at jahia dot com ]=---- --- -- - >> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227 >> Acacias, Switzerland >> twitter: @sergehuber <https://twitter.com/sergehuber> >> >> <http://jahiaone.com/register> >> JahiaOne <http://www.jahiaone.com/>, our international user conference >> is back! June 10-12 in Paris - Grab your tickets now >> <http://www.jahiaone.com/>! >> >> Jahia is a leading open source User eXperience Platform (UXP) vendor, >> relentlessly working at transforming a siloed industry into a user-driven >> one, beyond technology constraints - http://www.jahia.com >> >> >> On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck <bcanh...@googlemail.com> >> wrote: >> >>> Hey, >>> >>> yes I fully agree, also with the Spring-Boot stuff. >>> as already stated on the other thread, I think there are certain cases >>> where Docker images are useful. >>> For a POC, for CI I think a Docker Image is useful. In the end if you >>> want to run it in Production I rather have the Ansible setup. >>> >>> regards, Achim >>> >>> >>> 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >>> >>>> Hi Ed, >>>> >>>> I can't agree more ;) >>>> I fully agree about your points. >>>> >>>> I quite have the same view on Spring Boot ;) >>>> >>>> Regards >>>> JB >>>> >>>> >>>> On 04/13/2015 04:32 PM, Ed Welch wrote: >>>> >>>>> I've really enjoyed following this thread, and I have to say, as a >>>>> Docker skeptic surrounded by people who want to bash my brains in with >>>>> docker images, it's nice to hear some feedback from people who seem to >>>>> have >>>>> a healthy dose of skepticism like I do... >>>>> >>>>> So rather than rehash all the things I agree with that have been said >>>>> so far, I wanted to comment a few things I hadn't seen: >>>>> >>>>> The biggest discussion point I bring up with my peers regarding docker >>>>> that I've been using to kind of hold the floodgates back: Who is >>>>> responsible for updates to the underlying docker image OS? Our >>>>> organization is fairly segmented, we have a linux operations group, we >>>>> have >>>>> a development group. If our development group deploys 50 docker images, >>>>> all with a variety of distros inside them, different versions of >>>>> everything... What happens if there is a big vulnerability found >>>>> (think/remember bash). Is our linux team now on the hook to learn docker >>>>> and handle digging through dozens to hundreds of potentially very >>>>> different >>>>> docker images ( which would make you want to force standardization of your >>>>> docker images on a particular distro at a minimum ), or does the dev team >>>>> now own this responsibility? This is a hard question for our company to >>>>> answer... >>>>> >>>>> My other comment, is actually regarding what I think is the most >>>>> fantastic use case I've seen for docker, which was written up by Roland >>>>> Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/ >>>>> Using docker as part of your automated integration tests is a really >>>>> neat idea, especially if you work on a project that has to maintain >>>>> support >>>>> for piles of application servers, operating systems, and versions of java. >>>>> I think there is some real opportunity here as was previously mentioned, >>>>> to >>>>> build a docker image that sets up the OS, java, and karaf, and then at >>>>> test >>>>> time you deploy your app and run your tests. With this kind of model you >>>>> can just keep adding new docker images to your test suite and retire old >>>>> ones when you finally drop support for something ( *cough* java 6 *cough*) >>>>> >>>>> Good discussion, really have enjoyed reading! >>>>> >>>>> Ed >>>>> >>>>> >>>>> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin < >>>>> fragility...@gmail.com> wrote: >>>>> >>>>> I guess the barrier to be able to write code has been lowered enough >>>>>> that >>>>>> more people are able to do it, probably for the money. That goes >>>>>> hand in >>>>>> hand with the whole Docker thing where it feels there is an >>>>>> expectation >>>>>> that everything should be easy to do rather than accept that like any >>>>>> profession, you have to learn in order to become good. Nothing wrong >>>>>> with >>>>>> asking questions, but I feel quality of code will probably continue to >>>>>> decline with tools being the crutch. >>>>>> >>>>>> Anyhow, thanks for everyone's input. Karaf is a fantastic piece of >>>>>> software, I just wanted to make sure that things like Docker weren't >>>>>> going >>>>>> to cause it to be dumbed down. Obviously like any growing technology, >>>>>> modularity has some rough spots to iron out, but that doesn't mean we >>>>>> should give up. Developers can do what they want, I would like to >>>>>> continue >>>>>> to choose what fits my requirements best out of the technologies that >>>>>> are >>>>>> available. >>>>>> >>>>>> Ryan >>>>>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <bcanh...@googlemail.com> >>>>>> wrote: >>>>>> >>>>>> I can't agree more ... and some questions on stackoverflow or this >>>>>>> mailinglist just reflect that ... >>>>>>> "please solve my issue for me, cause I forgot to use my brain today" >>>>>>> :D >>>>>>> >>>>>>> regards, Achim >>>>>>> >>>>>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <fragility...@gmail.com>: >>>>>>> >>>>>>> Serge, >>>>>>>> >>>>>>>> Package the world applications were able to be built easily before >>>>>>>> Docker >>>>>>>> was around. Docker is simply a different way of deploying an >>>>>>>> application >>>>>>>> virtually. >>>>>>>> >>>>>>>> In my experience, developers who "package the world" with their >>>>>>>> code are >>>>>>>> usually either biased against modularity or just don't feel like >>>>>>>> putting >>>>>>>> forth the effort. Many technologies in use today take effort to >>>>>>>> figure >>>>>>>> out. A lot of developers seem to feel that any technology that >>>>>>>> requires >>>>>>>> effort above the maven shade plugin or using shell scripts to dump >>>>>>>> all >>>>>>>> their jars to a server isn't worth their time. >>>>>>>> >>>>>>>> Developers that care about the quality of the code or applications >>>>>>>> they >>>>>>>> produce won't be deterred from a technology they believe will help >>>>>>>> them >>>>>>>> make better applications just because it takes a little bit of >>>>>>>> effort. How >>>>>>>> did less experienced developers manage to survive when the only real >>>>>>>> choices for writing software was assembly, c or c++? >>>>>>>> >>>>>>>> Ryan >>>>>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <shu...@jahia.com> wrote: >>>>>>>> >>>>>>>> Very interesting thread guys :) >>>>>>>>> >>>>>>>>> Actually I recently started a project integrating Karaf with >>>>>>>>> ElasticSearch and for me it was a little like what you guys are >>>>>>>>> describing >>>>>>>>> in this thread. ES, at least in the early versions is quite >>>>>>>>> monolithic and >>>>>>>>> it would clearly benefit from a framework such as OSGi. For >>>>>>>>> example, the >>>>>>>>> clustering technology is quite interesting but why can't it be >>>>>>>>> reused >>>>>>>>> without all the other stuff ? Or maybe you want to wire things a >>>>>>>>> little >>>>>>>>> differently ? Not have everything directly listen to ports without >>>>>>>>> any >>>>>>>>> security but be able to plugin whatever filter or modules you need >>>>>>>>> ? >>>>>>>>> >>>>>>>>> Personally I think that what is really needed in OSGi is better >>>>>>>>> tooling, >>>>>>>>> especially for making it a lot simpler to build high quality and >>>>>>>>> minimalistic bundles. Using the maven-bundle-plugin or the >>>>>>>>> shader-plugin is >>>>>>>>> quite tedious and possibly error prone. I've built my own Maven >>>>>>>>> plugin on >>>>>>>>> top of the bundle plugin so that it can handle a lot more resources >>>>>>>>> (including JSPs that include taglibs for example) and that also >>>>>>>>> tries to be >>>>>>>>> smarter at generating import-package statements. This makes it >>>>>>>>> easier for >>>>>>>>> OSGi newbies to adopt the technology. >>>>>>>>> >>>>>>>>> I'm also worried that the initial learning curve of OSGi might be >>>>>>>>> putting less experienced developers off and more towards >>>>>>>>> package-the-world >>>>>>>>> solutions such as Docker, which while acceptable for some cases >>>>>>>>> such as >>>>>>>>> continuous integration, could also be dangerous if not maintained >>>>>>>>> properly. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Serge >>>>>>>>> >>>>>>>>> Le 11 avr. 2015 à 19:43, Niels <niels...@gmail.com> a écrit : >>>>>>>>> >>>>>>>>> Could not agree more Achim. Good fad indicators are high promises >>>>>>>>> which >>>>>>>>> are designed to target the ultimate need of decision makers to >>>>>>>>> deliver >>>>>>>>> software quicker and cheaper. Just rewind 10 years and we will >>>>>>>>> find the >>>>>>>>> exact same promises were made at the start of the SOA hype which >>>>>>>>> are now >>>>>>>>> touted by the microservices believers. At the end of the day >>>>>>>>> nothing will >>>>>>>>> prevent people from doing something really badly. >>>>>>>>> >>>>>>>>> I can see the value of docker but unless one really has all the >>>>>>>>> lifecycle ducks in a row I would not go down the path and >>>>>>>>> containerise the >>>>>>>>> all and sundry. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Niels >>>>>>>>> >>>>>>>>> On 12 Apr 2015, at 08:28, Ryan Moquin <fragility...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I used to work somewhere with other developers who always became >>>>>>>>> very >>>>>>>>> spiritual about whatever the latest "cool" developer technology or >>>>>>>>> methodology is. Microservices was one of them. It always made me >>>>>>>>> laugh >>>>>>>>> when I was told how super efficient and streamlined it was over >>>>>>>>> any other >>>>>>>>> solution because every fat jar deployed (Maven shade plugin abuse >>>>>>>>> in order >>>>>>>>> to be lazy) was between 500Mb and 1.7Gb. So much for being a >>>>>>>>> "micro"-service. >>>>>>>>> On Apr 8, 2015 2:55 PM, "Achim Nierbeck" <bcanh...@googlemail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I'm very ambivalent regarding this topic. >>>>>>>>>> >>>>>>>>>> On one hand I see a lot of move to Docker as heading for the holy >>>>>>>>>> grail >>>>>>>>>> on fixing all the issues we had in the past. #FAIL >>>>>>>>>> On the other hand I see some benefits of it, but still haven't >>>>>>>>>> found >>>>>>>>>> the concrete use-case where it did top a bar-metal or bare >>>>>>>>>> virtualized >>>>>>>>>> machine. >>>>>>>>>> >>>>>>>>>> It's absolutely true that it does have some benefits for easier >>>>>>>>>> deployment of "Infrastructure" but I also see a lot of failures >>>>>>>>>> in usage of >>>>>>>>>> Docker. Just to mention one, where did the init daemon go, it's >>>>>>>>>> been there >>>>>>>>>> for a reason in linux OS's and now we run applications on top of >>>>>>>>>> the system >>>>>>>>>> without it ... I don't feel comfortable with that, especially if >>>>>>>>>> you don't >>>>>>>>>> have a JVM as process running which starts spawning other >>>>>>>>>> processes (one >>>>>>>>>> might remember the zombie processes). >>>>>>>>>> In the end there are mostly more slopy/lazy people around[1] >>>>>>>>>> trying to >>>>>>>>>> get something going, that's why Docker will be sufficient enough, >>>>>>>>>> while the >>>>>>>>>> dynamic and re-configurable service oriented software >>>>>>>>>> architecture will be >>>>>>>>>> on the decrease. One just needs to follow that Microservice hype. >>>>>>>>>> Docker/SpringBoot are just part of this "mantra" :D >>>>>>>>>> In the end people will just split their Monolithic rubbish up to >>>>>>>>>> different small Monolithic piles of rubbish, but in case one of >>>>>>>>>> them is >>>>>>>>>> failing, they'll end up with one big failing pile of rubbish. >>>>>>>>>> >>>>>>>>>> Besides this rant, I think building a custom Karaf with your >>>>>>>>>> application on top, distributable as Docker image. Or as I did >>>>>>>>>> for a >>>>>>>>>> showcase building a base Karaf Docker Image for Continuous >>>>>>>>>> Integration/Delivery Pipeline is a good combination. As long as >>>>>>>>>> it's >>>>>>>>>> possible to configure the services inside this docker image from >>>>>>>>>> the >>>>>>>>>> outside. >>>>>>>>>> >>>>>>>>>> regards, Achim >>>>>>>>>> >>>>>>>>>> [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch. >>>>>>>>>> html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-04-08 17:34 GMT+02:00 Frank Lyaruu <fr...@dexels.com>: >>>>>>>>>> >>>>>>>>>> I agree, I do feel that vibe from time to time, mostly due to the >>>>>>>>>>> 'containers should be immutable' mantra. >>>>>>>>>>> >>>>>>>>>>> In my opinion, if you can get away with it, make it as dynamic >>>>>>>>>>> as you >>>>>>>>>>> want, but I guess we all know that building an application that >>>>>>>>>>> can be >>>>>>>>>>> reconfigured + updated on the fly is not easy at all. >>>>>>>>>>> >>>>>>>>>>> Anyway, while we're at it, I also wrote a few posts about OSGi + >>>>>>>>>>> Docker, with quite a different approach: I explore monitoring >>>>>>>>>>> the Docker >>>>>>>>>>> API to discover services, and inject those services as OSGi >>>>>>>>>>> configuration >>>>>>>>>>> data: >>>>>>>>>>> >>>>>>>>>>> http://www.codemonkey.nl/discovery/ >>>>>>>>>>> >>>>>>>>>>> I think OSGi and Docker can complement each other very nicely. >>>>>>>>>>> >>>>>>>>>>> regards, Frank >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin < >>>>>>>>>>> fragility...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Don't get me wrong, I don't mean that Docker and Karaf are >>>>>>>>>>>> interchangeable. I mean that it feels like, from quite a few >>>>>>>>>>>> things I >>>>>>>>>>>> read, that the trend may be to have a docker image built as >>>>>>>>>>>> part of every >>>>>>>>>>>> CI build. The purpose being that deployments should be fully >>>>>>>>>>>> immutable and >>>>>>>>>>>> if changes need to be made, then a new Docker image should be >>>>>>>>>>>> generated and >>>>>>>>>>>> deployed. >>>>>>>>>>>> >>>>>>>>>>>> One particular conversation that I felt really expressed this >>>>>>>>>>>> type of >>>>>>>>>>>> development track is this one: >>>>>>>>>>>> >>>>>>>>>>>> https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk >>>>>>>>>>>> >>>>>>>>>>>> Fabric8 used to be fully built on Karaf but has changed the >>>>>>>>>>>> approach >>>>>>>>>>>> to support other runtimes. Nothing is wrong with that, but if >>>>>>>>>>>> that pattern >>>>>>>>>>>> becomes a trend, then it feels that many of the nice features >>>>>>>>>>>> of Karaf will >>>>>>>>>>>> become "discouraged" and I can't see them being furthered in >>>>>>>>>>>> Karaf at that >>>>>>>>>>>> point. >>>>>>>>>>>> >>>>>>>>>>>> I love Karaf and everything it offers. I'm just a little >>>>>>>>>>>> concerned >>>>>>>>>>>> about how Docker is being pushed and the mindset that seems to >>>>>>>>>>>> evolving >>>>>>>>>>>> around it. The point is, I'm hoping that because Docker is >>>>>>>>>>>> immutable, that >>>>>>>>>>>> it doesn't cause all software development to shoot to be >>>>>>>>>>>> immutable. >>>>>>>>>>>> >>>>>>>>>>>> Hopefully that makes sense. :) Lots of new technologies allow >>>>>>>>>>>> developers to know less about software development and to write >>>>>>>>>>>> sloppier >>>>>>>>>>>> code because they can get away with it. While building things >>>>>>>>>>>> faster and >>>>>>>>>>>> minimizing redundant or error prone tasks is great. I guess >>>>>>>>>>>> I'm a little >>>>>>>>>>>> concerned about how Docker can be misused and the effect it >>>>>>>>>>>> could have. >>>>>>>>>>>> >>>>>>>>>>>> Hopefully that makes sense :) I have no problem embracing >>>>>>>>>>>> Docker as >>>>>>>>>>>> a container to run Karaf in, I'm just hoping Docker doesn't >>>>>>>>>>>> become a >>>>>>>>>>>> liability or stifler to Karaf. >>>>>>>>>>>> >>>>>>>>>>>> These of course are only my opinion of the research I've been >>>>>>>>>>>> doing >>>>>>>>>>>> on and off. I may be completely off the mark or >>>>>>>>>>>> misinterpreting things. >>>>>>>>>>>> >>>>>>>>>>>> Ryan >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak < >>>>>>>>>>>> vincent.zurc...@linagora.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I don't know if we can really compare Karaf and Docker. >>>>>>>>>>>>> I use OSGi to build modular applications. My bundles are Java >>>>>>>>>>>>> modules that I can assemble in one way or another. And I use >>>>>>>>>>>>> Karaf to >>>>>>>>>>>>> create a custom distribution of my OSGi applications. It is a >>>>>>>>>>>>> developer >>>>>>>>>>>>> thing. >>>>>>>>>>>>> >>>>>>>>>>>>> Now, I use Docker to execute applications in an isolated >>>>>>>>>>>>> container >>>>>>>>>>>>> on a machine. >>>>>>>>>>>>> Even on VM, running Docker can simplify support and debug for >>>>>>>>>>>>> applications. The fact we can isolate things is very helpful >>>>>>>>>>>>> for that. And >>>>>>>>>>>>> it is convenient to maximize the usage of VM resources. >>>>>>>>>>>>> >>>>>>>>>>>>> I do not see how one could replace the other. >>>>>>>>>>>>> BTW, I already run Karaf in Docker containers. And one of our >>>>>>>>>>>>> OSGi >>>>>>>>>>>>> applications (which runs in Karaf) can create and interact >>>>>>>>>>>>> with Docker >>>>>>>>>>>>> containers. So, you can make both of them together when you >>>>>>>>>>>>> need. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Le 08/04/2015 14:31, Ryan Moquin a écrit : >>>>>>>>>>>>> >>>>>>>>>>>>> I kind of feel like the big push of Docker in the development >>>>>>>>>>>>> community in general (as a whole, not talking about the Karaf >>>>>>>>>>>>> developer >>>>>>>>>>>>> community), will potentially cause a lack of innovation and >>>>>>>>>>>>> improvements in >>>>>>>>>>>>> the deploying of applications. Docker could become a crutch. >>>>>>>>>>>>> If an >>>>>>>>>>>>> application is slowly leaking memory over a 24 hour period, >>>>>>>>>>>>> why fix it? >>>>>>>>>>>>> When it crashes, just replace it with a new instance. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> May I say that cloud computing and virtualization in general >>>>>>>>>>>>> already >>>>>>>>>>>>> setup this kind of approach? >>>>>>>>>>>>> When a VM or a container has a problem, it may indeed be more >>>>>>>>>>>>> simple >>>>>>>>>>>>> to launch a new one, reconfigure your application to use it >>>>>>>>>>>>> and kill the >>>>>>>>>>>>> old one. But this is not new at all. And there are some little >>>>>>>>>>>>> things to >>>>>>>>>>>>> deal with, like reconfiguration. Docker works the same, at its >>>>>>>>>>>>> level. And >>>>>>>>>>>>> even if you can create new containers, the less procedures you >>>>>>>>>>>>> have in >>>>>>>>>>>>> production environments, the better it is. So, having >>>>>>>>>>>>> applications with >>>>>>>>>>>>> 99,99% uptime will always be better. >>>>>>>>>>>>> >>>>>>>>>>>>> BTW, Docker also has some limitations (with systems services >>>>>>>>>>>>> as an >>>>>>>>>>>>> example). >>>>>>>>>>>>> So, it comes with its own problems. And I do not expect >>>>>>>>>>>>> embedded >>>>>>>>>>>>> systems to use Docker (at least, for the moment). >>>>>>>>>>>>> >>>>>>>>>>>>> To summer it up, I would say OSGi brings modularity to Java >>>>>>>>>>>>> applications. >>>>>>>>>>>>> And that Docker brings modularity to deployments. That's not >>>>>>>>>>>>> the >>>>>>>>>>>>> same. >>>>>>>>>>>>> >>>>>>>>>>>>> My 2 cents, >>>>>>>>>>>>> >>>>>>>>>>>>> Vincent. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Vincent Zurczak >>>>>>>>>>>>> Linagora: www.linagora.com >>>>>>>>>>>>> >>>>>>>>>>>>> <twitter_16.png> <https://twitter.com/VincentZurczak> >>>>>>>>>>>>> <linkedin_16.png> >>>>>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> >>>>>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png> >>>>>>>>>>>>> <http://vzurczak.wordpress.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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> jbono...@apache.org >>>> 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 >>> >>> >> >
