Art, You can track the progress here: https://issues.apache.org/jira/browse/AMQ-7087
I just pushed a commit to my github and posted some comments about it. The main problem with JDK 11 is they made it modular and took out java EE classes so we now have to include new jars. OSGi support is also broken now (no surprise). If you search online there is more detailed information about the specific issues with upgrading from JDK 8 to 11. If anyone wants to help out with the JDK 11 stuff feel free. (especially OSGi as my experience with it is limited0 I think it makes sense we sort everything out with running on JDK 11 in order to do 5.16.0 On Thu, Nov 29, 2018 at 12:45 PM Arthur Naseef <a...@amlinv.com> wrote: > @Gary Tully <gary.tu...@gmail.com> - thank you for the clarification. > > @Christopher Shannon <christopher.l.shan...@gmail.com> - for my personal > learning -- do you have a link to a good read on what it takes to support > JDK 11? Or can you give a brief list of issues? I'm curious of the > technical parts involved. > > Art > > > On Thu, Nov 29, 2018 at 8:14 AM Jamie G. <jamie.goody...@gmail.com> wrote: > >> JDK 11 support sounds great :) >> On Thu, Nov 29, 2018 at 11:34 AM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> > >> > It sounds good for JDK 11. It's something I planned to start for a while >> > (now that JDK 11 support is complete in Karaf). Don't hesitate to ping >> > me if I can help. >> > >> > Thanks >> > Regards >> > JB >> > >> > On 29/11/2018 16:02, Christopher Shannon wrote: >> > > I'm actually working on getting JDK 11 support right now. The idea is >> > > ActiveMQ will still have a compile/runtime target of JDK 8 but will >> run >> > > without issue on JDK 11 and be able to be built with JDK 11 etc. We >> need >> > > to have that done before going to 5.16.0 as long as a bunch of >> dependency >> > > updates. Otherwise there isn't anything else stopping us from doing a >> > > 5.16.0 >> > > >> > > On Thu, Nov 29, 2018 at 9:03 AM Clebert Suconic < >> clebert.suco...@gmail.com> >> > > wrote: >> > > >> > >> iMHO since you are now a commuter you have the power to call it >> 5,16.0. And >> > >> even make a release when you are ready. >> > >> >> > >> On Thu, Nov 29, 2018 at 7:53 AM Jamie G. <jamie.goody...@gmail.com> >> wrote: >> > >> >> > >>> Hi Gary, >> > >>> >> > >>> Just want to clarify, you're asking to wait for 5.16.0 to be >> released, >> > >>> than bring in the refactoring effort? >> > >>> >> > >>> If you feel 5.16.0 is imminent than I'm happy to hold off. I'd >> prefer >> > >>> to get this in sooner rather than later so as to reduce the amount >> of >> > >>> rebasing/cherry picking i need to do in the meantime. >> > >>> >> > >>> By the way, thank you for the support and looking at the code. I >> > >>> really appreciate it :) >> > >>> >> > >>> Cheers, >> > >>> Jamie >> > >>> On Thu, Nov 29, 2018 at 8:56 AM Gary Tully <gary.tu...@gmail.com> >> wrote: >> > >>>> >> > >>>> Hey Arthur, >> > >>>> I am not asserting that they need to be small. >> > >>>> I am pointing out that they currently are small changes; there has >> > >>>> been no significant refactor to date; it is all very conservative. >> > >>>> Release 5.16.0 as a line in the sand, then move code around to >> make it >> > >>>> better etc.. go for it. >> > >>>> >> > >>>> I know too well it is not perfect and I think it is great that >> there >> > >>>> is interest in making it better. >> > >>>> >> > >>>> On Wed, 28 Nov 2018 at 16:22, Arthur Naseef <a...@amlinv.com> >> wrote: >> > >>>>> >> > >>>>> Hey Gary - I agree that these changes belong on a minor version >> > >>> increase. >> > >>>>> >> > >>>>> What I don't understand is the assertion that the changes between >> > >>> 5.15.x >> > >>>>> and 5.16.0 need to be small. Given that the minor version bump >> can >> > >>> mean >> > >>>>> significant changes, as long as they are backward compatible, I >> see >> > >> no >> > >>>>> reason to adhere to a small set of changes between 5.15.x and >> 5.16.0. >> > >>> Add >> > >>>>> to that fact that ActiveMQ's minor releases are sometimes really >> > >> major >> > >>>>> changes (i.e. include breaking changes), and that makes even less >> > >>> sense. >> > >>>>> >> > >>>>> Is there something more to this that perhaps I'm missing? >> > >>>>> >> > >>>>> Making the code more maintainable by the community, as ActiveMQ >> is an >> > >>>>> Apache *community* project, is the goal. As for it being >> maintained >> > >>> for 7 >> > >>>>> years, that's great. However, I'm sure you'll agree it's not >> > >> perfect, >> > >>> and >> > >>>>> community improvements are welcome. >> > >>>>> >> > >>>>> Art >> > >>>>> >> > >>>>> >> > >>>>> On Wed, Nov 28, 2018 at 3:30 AM Gary Tully <gary.tu...@gmail.com> >> > >>> wrote: >> > >>>>> >> > >>>>>> Jamie, >> > >>>>>> you are missing my point. it is a tradeoff plain and simple. >> easier >> > >>> to >> > >>>>>> maintain for who? It has been carefully maintained for more than >> 7 >> > >>>>>> years. >> > >>>>>> Do refactoring at the beginning of a release cycle, not at the >> end. >> > >>>>>> diffs between 5.15.x and 5.16 will be meaningless otherwise. >> > >>>>>> push out 5.16.0, which has loads of incremental (non refactored) >> > >>> small >> > >>>>>> changes. Then refactor away on master for 5.17.0 and make it >> better >> > >>> in >> > >>>>>> any way that works for the future and for you. >> > >>>>>> On Tue, 27 Nov 2018 at 15:34, Jamie G. <jamie.goody...@gmail.com >> > >> > >>> wrote: >> > >>>>>>> >> > >>>>>>> Hi Gary, >> > >>>>>>> >> > >>>>>>> To address your concerns: >> > >>>>>>> >> > >>>>>>> 1. The code is being cleaned up, not completely rewritten. This >> > >> is >> > >>>>>>> making it easier to maintain over the monolithic classes. It's >> > >>> also >> > >>>>>>> why it was brought to the community… to review it and be sure >> the >> > >>>>>>> changes are just cleaning it up. There was no intent to change >> > >> the >> > >>>>>>> logic for the reason that you suggested. >> > >>>>>>> >> > >>>>>>> 2. I answered above, its easy on the back port as we can just >> > >> make >> > >>> it >> > >>>>>>> a part of 5.15.9 (too my understanding the community supports >> > >>> master >> > >>>>>>> and the last release branch). There are little differences >> > >>> between 16 >> > >>>>>>> and 15.9 in the KahaDB realm. So placing it in 15.9 does not >> > >>> change >> > >>>>>>> any way it operates or works. It only cleans up the readability >> > >> of >> > >>>>>>> the code. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> "A dream you dream alone is only a dream. A dream you dream >> > >>> together >> > >>>>>>> is reality." >> > >>>>>>> >> > >>>>>>> ― John Lennon >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Cheers, >> > >>>>>>> Jamie >> > >>>>>>> On Tue, Nov 27, 2018 at 8:29 AM Gary Tully < >> gary.tu...@gmail.com >> > >>> >> > >>> wrote: >> > >>>>>>>> >> > >>>>>>>> Hi Jamie G, >> > >>>>>>>> There are a few trade offs to consider: >> > >>>>>>>> 1) those familiar with the code will have to reacquaint >> > >>> themselves >> > >>>>>>>> with anything that is refactored >> > >>>>>>>> 2) backporting fixes will be more difficult when the code >> > >>> structure >> > >>>>>> changes >> > >>>>>>>> >> > >>>>>>>> Of the two, I think #2 is more critical. >> > >>>>>>>> >> > >>>>>>>> On #1: >> > >>>>>>>> context builds up over time and code structure is an integral >> > >>> part of >> > >>>>>>>> that, for better or for worse. >> > >>>>>>>> Switching context is not something us humans like doing, most >> > >>>>>>>> especially when stability is a key concern. >> > >>>>>>>> >> > >>>>>>>> Refactoring with purpose (for a new feature) can be great, >> > >> doing >> > >>> it at >> > >>>>>>>> this stage for readability may be less great. >> > >>>>>>>> >> > >>>>>>>> Mr. W. B. Yeats put it nicely: "tread softly because you tread >> > >>> on my >> > >>>>>> dreams" >> > >>>>>>>> >> > >>>>>>>> s/dreams/mental model/ >> > >>>>>>>> On Mon, 26 Nov 2018 at 19:44, Christopher Shannon >> > >>>>>>>> <christopher.l.shan...@gmail.com> wrote: >> > >>>>>>>>> >> > >>>>>>>>> I didn't say I definitely wouldn't support it but I just want >> > >>> to >> > >>>>>> make sure >> > >>>>>>>>> we are careful and the benefits of the refactor (in this case >> > >>>>>> improved >> > >>>>>>>>> maintainability) are really going to be worth the risk >> > >>> specifically >> > >>>>>> because >> > >>>>>>>>> of the component being touched. Too often things get >> > >>> committed and >> > >>>>>> then >> > >>>>>>>>> issues are uncovered with the patch later that were missed. >> > >>>>>>>>> >> > >>>>>>>>> Some parts of the broker are critical and this is one of them >> > >>>>>> because a bug >> > >>>>>>>>> that corrupts a store could lead to losing lots of production >> > >>> data >> > >>>>>> which is >> > >>>>>>>>> a very different type of bug than a random web console bug or >> > >>>>>> transport >> > >>>>>>>>> error that just causes an error with a single client or with >> > >> a >> > >>> single >> > >>>>>>>>> message. Granted the risk of a critical bug being introduced >> > >>> with a >> > >>>>>>>>> refactor like this is not very high but if there is one it >> > >>> could have >> > >>>>>>>>> pretty bad consequences. >> > >>>>>>>>> >> > >>>>>>>>> Now all that being said ... as long as we are careful to make >> > >>> sure >> > >>>>>> all >> > >>>>>>>>> tests pass and have a few people thoroughly review it (such >> > >> as >> > >>> Gary >> > >>>>>> who has >> > >>>>>>>>> the most experience out of anyone in KahaDB) then I would +1 >> > >>> the >> > >>>>>> change for >> > >>>>>>>>> a 5.16.0 release. >> > >>>>>>>>> >> > >>>>>>>>> On Mon, Nov 26, 2018 at 2:07 PM Arthur Naseef < >> > >> a...@amlinv.com> >> > >>>>>> wrote: >> > >>>>>>>>> >> > >>>>>>>>>> Improving the existing code is a great goal. >> > >>>>>>>>>> >> > >>>>>>>>>> While cleaning up code is nice KahaDB has gotten pretty >> > >>> stable >> > >>>>>> over the >> > >>>>>>>>>>> years and doing a bunch of refactoring just opens it up >> > >> to >> > >>> new >> > >>>>>> bugs that >> > >>>>>>>>>>> have to be fixed. Fixing bugs is not a problem however I >> > >>> tend >> > >>>>>> to be more >> > >>>>>>>>>>> sensitive to store related changes because of the >> > >> possible >> > >>> data >> > >>>>>> loss or >> > >>>>>>>>>>> corruption issues to production data that can occur from >> > >>> store >> > >>>>>> bugs vs >> > >>>>>>>>>> some >> > >>>>>>>>>>> other random bug in the broker. >> > >>>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> I understand the desire to avoid the risk of introducing >> > >>> bugs. >> > >>>>>> However, as >> > >>>>>>>>>> long as the project is active and maintained, that really >> > >>> isn't a >> > >>>>>> valid >> > >>>>>>>>>> approach to its maintenance overall. >> > >>>>>>>>>> >> > >>>>>>>>>> So that leads us to the question of risk mitigation. >> > >>> Build-time >> > >>>>>> tests are >> > >>>>>>>>>> an industry standard, and ActiveMQ certainly has a large >> > >>> number of >> > >>>>>> such >> > >>>>>>>>>> tests. Code reviews are another best-practice, and there >> > >> are >> > >>>>>> multiple >> > >>>>>>>>>> individuals looking at these code changes now. More are >> > >>> always >> > >>>>>> welcome, >> > >>>>>>>>>> and access is certainly not a problem! >> > >>>>>>>>>> >> > >>>>>>>>>> If there are specific concerns within the code changes, >> > >> let's >> > >>>>>> discuss >> > >>>>>>>>>> them. It'll be great to have actual technical discussions! >> > >>>>>>>>>> >> > >>>>>>>>>> As for the concern that this is the broker's storage, >> > >> similar >> > >>>>>> arguments >> > >>>>>>>>>> could be made for just about any part of the code. >> > >> Reliable >> > >>>>>> handling of >> > >>>>>>>>>> messages is ActiveMQ's core benefit to its users. >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>>> FWIW, the current community goal is for ActiveMQ Artemis >> > >> to >> > >>>>>> become >> > >>>>>>>>>> ActiveMQ >> > >>>>>>>>>> >> > >>>>>>>>>> 6.x when acceptable feature parity is reached (which is >> > >>> actively >> > >>>>>> being >> > >>>>>>>>>>> worked on). >> > >>>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> Whether Artemis will eventually become ActiveMQ 6.x is not >> > >>>>>> pertitent to >> > >>>>>>>>>> this discussion. Let's not open that discussion as part of >> > >>> this >> > >>>>>> technical >> > >>>>>>>>>> code conversation. >> > >>>>>>>>>> >> > >>>>>>>>>> Making the existing code base, which has heavy usage in the >> > >>>>>> industry, more >> > >>>>>>>>>> maintainable is always a good goal to achieve. And having >> > >>> more >> > >>>>>> folks in >> > >>>>>>>>>> the community engaging in working on the project can only >> > >>> benefit >> > >>>>>> the >> > >>>>>>>>>> entire community regardless of the long-term destination. >> > >>>>>>>>>> >> > >>>>>>>>>> Art >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> On Mon, Nov 26, 2018 at 10:22 AM Justin Bertram < >> > >>>>>> jbert...@apache.org> >> > >>>>>>>>>> wrote: >> > >>>>>>>>>> >> > >>>>>>>>>>> FWIW, the current community goal is for ActiveMQ Artemis >> > >> to >> > >>>>>> become >> > >>>>>>>>>> ActiveMQ >> > >>>>>>>>>>> 6.x when acceptable feature parity is reached (which is >> > >>> actively >> > >>>>>> being >> > >>>>>>>>>>> worked on). >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> Justin >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> On Mon, Nov 26, 2018 at 11:01 AM Jamie G. < >> > >>>>>> jamie.goody...@gmail.com> >> > >>>>>>>>>>> wrote: >> > >>>>>>>>>>> >> > >>>>>>>>>>>> The idea here is to ensure that it’s development and >> > >>>>>> maintenance >> > >>>>>>>>>>>> moving forward is easier as we work to make it better >> > >> in >> > >>> the >> > >>>>>> future. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> KahaDB currently has massive classes (KahaDBStore, >> > >>>>>> MessageDatabase) >> > >>>>>>>>>>>> and code base and is extremely hard to follow. My >> > >>> desire to >> > >>>>>> do this >> > >>>>>>>>>>>> was to make this so we could make the continued >> > >>> maintenance >> > >>>>>> easier and >> > >>>>>>>>>>>> also make it more inviting to improvements. The unit >> > >>> tests >> > >>>>>> all pass, >> > >>>>>>>>>>>> so as long as we have a good solid testing coverage, >> > >> the >> > >>> risks >> > >>>>>> are not >> > >>>>>>>>>>>> huge. If a bug appears to be introduced, than we may >> > >>> have >> > >>>>>> uncovered a >> > >>>>>>>>>>>> testing hole - finding these is a good thing. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> Since we are going to continue to support ActiveMQ >> > >> moving >> > >>>>>> forward, >> > >>>>>>>>>>>> it’s a good idea to make it more maintainable. My >> > >>> motivation >> > >>>>>> to doing >> > >>>>>>>>>>>> this was spurred by the recent JIRAs surrounding >> > >> KahaDB I >> > >>>>>> helped out >> > >>>>>>>>>>>> upon. I really believe this is a good improvement to >> > >>> help >> > >>>>>> moving >> > >>>>>>>>>>>> ActiveMQ forward. >> > >>>>>>>>>>>> On Mon, Nov 26, 2018 at 12:33 PM Christopher Shannon >> > >>>>>>>>>>>> <christopher.l.shan...@gmail.com> wrote: >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> I'm not really sure this is worthwhile or something >> > >> we >> > >>> want >> > >>>>>> to do...I >> > >>>>>>>>>>>> would >> > >>>>>>>>>>>>> have to think about it more before I gave it a +1. >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> While cleaning up code is nice KahaDB has gotten >> > >> pretty >> > >>>>>> stable over >> > >>>>>>>>>> the >> > >>>>>>>>>>>>> years and doing a bunch of refactoring just opens it >> > >>> up to >> > >>>>>> new bugs >> > >>>>>>>>>>> that >> > >>>>>>>>>>>>> have to be fixed. Fixing bugs is not a problem >> > >>> however I >> > >>>>>> tend to be >> > >>>>>>>>>>> more >> > >>>>>>>>>>>>> sensitive to store related changes because of the >> > >>> possible >> > >>>>>> data loss >> > >>>>>>>>>> or >> > >>>>>>>>>>>>> corruption issues to production data that can occur >> > >>> from >> > >>>>>> store bugs >> > >>>>>>>>>> vs >> > >>>>>>>>>>>> some >> > >>>>>>>>>>>>> other random bug in the broker. >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> On Sun, Nov 25, 2018 at 11:59 PM Jean-Baptiste >> > >> Onofré < >> > >>>>>>>>>> j...@nanthrax.net >> > >>>>>>>>>>>> >> > >>>>>>>>>>>>> wrote: >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>>> OK, got it. It's more a syntax/codebase >> > >> organization >> > >>>>>> refactoring. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> If there's no impact on the behavior and features, >> > >>> +1 from >> > >>>>>> my side. >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Regards >> > >>>>>>>>>>>>>> JB >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> On 25/11/2018 21:21, Jamie G. wrote: >> > >>>>>>>>>>>>>>> Initially its to make KahaDB classes easier to >> > >>> read & >> > >>>>>> maintain. >> > >>>>>>>>>>>>>>> Eventually it will help in features/performance; >> > >>> smaller >> > >>>>>> classes >> > >>>>>>>>>>> are >> > >>>>>>>>>>>>>>> easier to grok, easier to see improvements. >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> Instead of trying to refactor all of it in one >> > >> go, >> > >>> I'm >> > >>>>>> taking the >> > >>>>>>>>>>>>>>> approach of one area at a time. >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> One pass for breaking out objects. >> > >>>>>>>>>>>>>>> Another pass for small functional improvements. >> > >>>>>>>>>>>>>>> Perhaps future passes for new Java features >> > >> (bring >> > >>> all >> > >>>>>> code up to >> > >>>>>>>>>>>> Java >> > >>>>>>>>>>>>>>> 8 perhaps?). >> > >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> On Sun, Nov 25, 2018 at 4:32 PM Jean-Baptiste >> > >>> Onofré < >> > >>>>>>>>>>>> j...@nanthrax.net> >> > >>>>>>>>>>>>>> wrote: >> > >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> Hi Jamie, >> > >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> That's interesting. >> > >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> What's the rationale behind the refactoring ? >> > >> New >> > >>>>>> features or >> > >>>>>>>>>> perf >> > >>>>>>>>>>>>>>>> improvements ? >> > >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> Regards >> > >>>>>>>>>>>>>>>> JB >> > >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> On 25/11/2018 20:16, Jamie G. wrote: >> > >>>>>>>>>>>>>>>>> Hi All, >> > >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> I've taken some time to prototype a refactored >> > >>>>>> KahaDBStore >> > >>>>>>>>>> class: >> > >>>>>>>>>>>>>>>>> >> > >>>>>> https://github.com/jgoodyear/activemq/tree/KahaDBRefactor >> > >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> As KahaDBStore exists in Master, it contains 7 >> > >>> internal >> > >>>>>>>>>> classes, >> > >>>>>>>>>>>> over >> > >>>>>>>>>>>>>>>>> some 1677 lines of code. >> > >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> In my refactor branch I've separated out those >> > >>> classes >> > >>>>>> into >> > >>>>>>>>>> their >> > >>>>>>>>>>>> own >> > >>>>>>>>>>>>>>>>> files, and applied some gentle clean code >> > >>> practices to >> > >>>>>> help >> > >>>>>>>>>> make >> > >>>>>>>>>>>> these >> > >>>>>>>>>>>>>>>>> files easier to read and maintain. >> > >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> I'd like to gather feed back from the >> > >> community; >> > >>> I've >> > >>>>>> taken >> > >>>>>>>>>> care >> > >>>>>>>>>>> to >> > >>>>>>>>>>>>>>>>> change functionality as little as possible - >> > >> the >> > >>> aim >> > >>>>>> here is to >> > >>>>>>>>>>>> reduce >> > >>>>>>>>>>>>>>>>> complexity and improve maintainability. If the >> > >>>>>> community feels >> > >>>>>>>>>>>> this is >> > >>>>>>>>>>>>>>>>> a worth while goal than I'll open a card on >> > >> Jira >> > >>> & >> > >>>>>> prepare a >> > >>>>>>>>>> PR. >> > >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> Notes: >> > >>>>>>>>>>>>>>>>> ActiveMQ KahaDB Store and ActiveMQ-Unit-Tests >> > >>> suites >> > >>>>>> remain >> > >>>>>>>>>>>> passing >> > >>>>>>>>>>>>>>>>> after refactor. >> > >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> Cheers, >> > >>>>>>>>>>>>>>>>> Jamie >> > >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> -- >> > >>>>>>>>>>>>>>>> Jean-Baptiste Onofré >> > >>>>>>>>>>>>>>>> jbono...@apache.org >> > >>>>>>>>>>>>>>>> http://blog.nanthrax.net >> > >>>>>>>>>>>>>>>> Talend - http://www.talend.com >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> -- >> > >>>>>>>>>>>>>> Jean-Baptiste Onofré >> > >>>>>>>>>>>>>> jbono...@apache.org >> > >>>>>>>>>>>>>> http://blog.nanthrax.net >> > >>>>>>>>>>>>>> Talend - http://www.talend.com >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>> >> > >>> >> > >> -- >> > >> Clebert Suconic >> > >> >> > > >> > >> > -- >> > Jean-Baptiste Onofré >> > jbono...@apache.org >> > http://blog.nanthrax.net >> > Talend - http://www.talend.com >> >
