Hello, Status for now: For a 3.0:
- Milamber (*) - Antonio Gomes Rodrigues - me (*) For a 2.14: - sebb (*) For a 3.0 if it does not holds next release for too long (this is not the case, for now release 3.0 is blocked by release of HttpClient 4.5.2 and this discussion): - Felix (*) (*) Binding as PMC member Do I need to open a technical vote on this issue or can we go for a 3.0.0 ? I will wait 24 hours before starting this technical vote. Regards Philippe On Tue, Feb 2, 2016 at 11:48 PM, Philippe Mouawad < philippe.moua...@gmail.com> wrote: > Hi, > If this is to block next release, then I will go for a 2.14 although I > think that this numbering makes people think JMeter is only releasing minor > fixes and think they don't have to upgrade. > > Please sebb, can you give your final thought ? > thankd > > Regards > Philippe > > > On Monday, January 25, 2016, Philippe Mouawad <philippe.moua...@gmail.com> > wrote: > >> Hello, >> Regarding API Changes, I think the following changes are breaking >> API/Plans (in the sense of JMeter): >> >> - In RandomTimer class, protected instance timer has been replaced by >> getTimer() protected method, this is related to Bug 58100 >> <http://bz.apache.org/bugzilla/show_bug.cgi?id=58100>. This may >> impact 3rd party plugins. >> - org.apache.jmeter.gui.util.ButtonPanel has been removed, if you use >> it in your 3rd party plugin or custom development ensure you update your >> code. See Bug 58687 >> <http://bz.apache.org/bugzilla/show_bug.cgi?id=58687> >> - WebService(SOAP) Request and HTML Parameter Mask which were >> deprecated in 2.13 version, have now been removed following our >> deprecation >> strategy >> - org.apache.jmeter.protocol.http.visualizers.RequestViewHTTP.getQueryMap >> signature has changed, if you use it ensure you update your code. See Bug >> 58845 <http://bz.apache.org/bugzilla/show_bug.cgi?id=58845> >> >> >> And switching to 3.0 would allow us to be more aggressive in some changes: >> >> - Since version 3.0, you can use Nashorn Engine (default javascript >> engine is Rhino) under Java8 for Elements that use Javascript Engine >> (__javaScript, IfController). If you want to use it, use property >> javascript.use_rhino=false, see Bug 58406 >> <http://bz.apache.org/bugzilla/show_bug.cgi?id=58406>. Note in future >> versions, we will switch to Nashorn by default, so users are encouraged to >> report any issue related to broken code when using Nashorn instead of >> Rhino. => Switch to use_rhino=true >> >> >> Even if we did similar changes in previous versions and did not respect >> the versioning system, I think we should do it starting from now. >> >> Regards >> >> On Sun, Jan 24, 2016 at 1:38 PM, sebb <seb...@gmail.com> wrote: >> >>> On 24 January 2016 at 11:30, Felix Schumacher >>> <felix.schumac...@internetallee.de> wrote: >>> > Am 14.01.2016 um 15:16 schrieb Philippe Mouawad: >>> >> >>> >> Hi all, >>> >> Can we go for a 3.0 or do we need to discuss it more or eventually >>> run a >>> >> vote on this ? >>> > >>> > I think there are two discussions in this thread. The first one was >>> about >>> > using semver for our versioning scheme. That scheme seemed to be >>> accepted by >>> > everyone. >>> > >>> > The other point was about the release number. >>> > >>> > The reasons that were brought up for a version 3.0 where of two kinds. >>> > >>> > 1. marketing (making it clear, that the jmeter from today is quite >>> > different from the jmeter from years ago.) >>> > >>> > 2. semver. Here it wasn't clear, whether the changes in jmeter from >>> the >>> > last version where sufficient to call for a major release. >>> > >>> > I have run jpapicmp (https://siom79.github.io/japicmp/) comparing the >>> last >>> > three releases (including the next) and the tool reported major api >>> changes >>> > in all of them. So while a 3.0 would be valid for semver, it would >>> have been >>> > for the last two versions, too. >>> > >>> > I am still OK with going for semver for the versioning, but we might >>> have to >>> > discuss how we want to measure the api changes, so that we don't need >>> to >>> > discuss version numbers in the future. >>> > >>> > I am OK with a 3.0 considering the output of japicmp showed breaking >>> api >>> > changes, which would result in a new major release number. >>> >>> Breaking API changes shown by japicmp have very little bearing on >>> whether JMeter users are affected. >>> JMeter users are only likely to be affected by behaviourial changes. >>> >>> Even plugin writers are unlikely to be affected by the majority of API >>> changes shown by japicmp. >>> >>> For example, not all public classes and methods are intended for use >>> by plugin writers. >>> >>> The output of a tool such as japicmp is not particularly useful >>> witthout proper analysis of the results. >>> This would be true even of low-level library jars, as classes often >>> have to be made public or protected even though they are not intended >>> as part of the public API. >>> >>> Sorry, but I'm not sure that the analysis is much use in the case of >>> JMeter. >>> >>> > Regards, >>> > Felix >>> > >>> > >>> >> >>> >> Thanks >>> >> Regards >>> >> >>> >> On Wed, Jan 13, 2016 at 10:18 PM, Antonio Gomes Rodrigues >>> >> <ra0...@gmail.com> >>> >> wrote: >>> >> >>> >>> Hi >>> >>> >>> >>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad < >>> philippe.moua...@gmail.com>: >>> >>> >>> >>>> On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues < >>> >>> >>> >>> ra0...@gmail.com >>> >>>> >>> >>>> wrote: >>> >>>> >>> >>>>> Hi, >>> >>>>> >>> >>>>> My opinion >>> >>>>> >>> >>>>> I think it's a good idea to rename to 3.0 the next release, >>> because: >>> >>>>> Old release of JMeter have bad reputation (complex to use, bad >>> >>>> >>> >>>> performance, >>> >>>>> >>> >>>>> etc.) to people >>> >>>>> People think that JMeter evolve slowly (I have even heard it from >>> an >>> >>>> >>> >>>> Apache >>> >>>>> >>> >>>>> (not JMeter) commiter >>> >>>>> Same reason than Milamber >>> >>>>> >>> >>>>> Remove old things (HC3.1 support, etc.) is great to because each >>> time I >>> >>>>> show JMeter to someone, he is afraid by the GUI >>> >>>>> >>> >>>>> Remove some listener is great to (the two proposed by Philippe >>> Mouawad) >>> >>>> >>> >>>> and >>> >>>>> >>> >>>>> maybe other (I think about Monitor Results, >>> >>>> >>> >>>> +1 I think there are now better ways to do this and jmeter-plugins >>> has 1 >>> >>>> >>> >>>> >>> >>>>> Graph Results, >>> >>>> >>> >>>> +0, It can be useful in Debugging maybe >>> >>>> >>> >>>> >>> >>>>> Assertion Results >>> >>>>> >>> >>>> I prefer your idea of debug listener than removal, because from >>> >>>> Stackoverflow questions, I think this one is used >>> >>>> >>> >>>>> About listener I think it will be great to brain storming about >>> them >>> >>>>> because I think: >>> >>>>> they are not modern >>> >>>>> it misses some very interesting/important (some are present in >>> JMeter >>> >>>>> plugins) while JMeter have some very few helpfull >>> >>>>> >>> >>>> I tend to think that new report dashboard feature answers this. As >>> we do >>> >>> >>> >>> no >>> >>>> >>> >>>> favor GUI testing, I am not sure we should enhance this with. >>> >>>> For live graphing, we should I think enhance BackendLIstener with a >>> JDBC >>> >>>> persister at least. >>> >>>> >>> >>> I think too >>> >>> >>> >>> My complete opinion >>> >>> Have the new report dashboard feature to have a complete report at >>> the >>> >>> end >>> >>> of the load test >>> >>> Have BackendLIstener to live graphing. Have a great live graphing >>> allow >>> >>> to >>> >>> check the load test and stop/modify it if it's necessary (bad >>> >>> configuration, bad data, etc.). It's usefull too for some test (for >>> >>> example >>> >>> chekc in live the result of a chaos monkey) >>> >>> Only keep a few listeners in JMeter core (deprecate it and remove it) >>> >>> Install JMeter Plugins to have more listener if we want to display >>> >>> graphic >>> >>> in JMeter >>> >>> >>> >>> >>> >>> For the moment I have not test report dashboard feature but the >>> >>> screenshot >>> >>> I have seen are great. I will check them asap to check if something >>> is >>> >>> missing >>> >>> >>> >>> About BackendLIstener I have already test it and it's great. Maybe it >>> >>> need >>> >>> some GUI improvement and new supported backend (ElasticSearch, >>> database) >>> >>> >>> >>> >>> >>>> >>> >>>>> I think it will be great to separate the listener in two parts: >>> >>>>> >>> >>>> Nice idea. >>> >>>> >>> >>>> >>> >>>>> listener (all the interesting listener (Aggregate Graph, Response >>> Time >>> >>>>> Graph, etc.) >>> >>>>> debug listener (Assertion Results, JSR223 Listener, etc.) >>> >>>>> >>> >>>>> It will be great to have project which regroup jmx files + results >>> + >>> >>> >>> >>> data >>> >>>>> >>> >>>>> files like commercial tools (a zip file is sufficient) >>> >>>>> >>> >>>> Can you clarify this ? >>> >>>> >>> >>> Instead having one or more JMX files + data files (csv) + result load >>> >>> test >>> >>> files (csv, etc.) I think it will be better to have a single file >>> which >>> >>> contains all these files. >>> >>> Or two files (one for the load scripts + data and the other for the >>> >>> results >>> >>> files) >>> >>> >>> >>> It will allow to easily send to a collegue the complete script with >>> all >>> >>> necessary files (csv, etc.) >>> >>> The same to send the result of a load test >>> >>> >>> >>> >>> >>> >>> >>>>> It will be great to have 2 modes to hide some sampler/listener/etc. >>> >>>>> One for newcomer and another for expert. >>> >>>>> It will allow to don't scary newcomers the first time he launch >>> JMeter >>> >>>>> >>> >>>> I like this idea, knowing that we have this property that we could >>> use: >>> >>>> #jmeter.expertMode=true >>> >>>> >>> >>>>> Or have one mode by technology tested (http, database, etc.) + >>> expert >>> >>>> >>> >>>> mode >>> >>>>> >>> >>>>> will all >>> >>>>> >>> >>>>> Maybe remove some timer (I don't know is they are all used) >>> >>>>> >>> >>>> I think that all of them have their use but maybe put some only in >>> >>>> expert >>> >>>> mode. >>> >>>> >>> >>>> Another field of deprecation is maybe the BSF elements that seem to >>> me >>> >>>> better replaced by JSR223 elements. >>> >>>> >>> >>> +1 >>> >>> >>> >>>> Anyway thanks for all those ideas. >>> >>>> >>> >>>>> Antonio >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> 2016-01-08 0:48 GMT+01:00 Milamber <milam...@apache.org>: >>> >>>>> >>> >>>>>> Hello, >>> >>>>>> >>> >>>>>> For me, the jump to 3.0 must be done for next version. >>> >>>>>> >>> >>>>>> >>> >>>>>> Remember: JMeter 2.0.0 was release in 2004, so 12 years ago and 23 >>> >>>>>> versions have been release since! >>> >>>>>> >>> >>>>>> A lot of works since 2004 on the user interface (the toolbar, >>> sampler >>> >>>>>> forms, graphical listener, etc.) >>> >>>>>> >>> >>>>>> A lot of works under the woods, to improve the JMeter internal >>> >>>>>> performance, the samplers like HTTP request (default HC4), the >>> >>> >>> >>> parallel >>> >>>>>> >>> >>>>>> resource download, etc) >>> >>>>>> >>> >>>>>> A lot of works to improve the user experience (like the Regexp >>> >>> >>> >>> tester, >>> >>>>> >>> >>>>> the >>> >>>>>> >>> >>>>>> templates box, the search on the JMeter tree, log pane, OS >>> >>> >>> >>> integration >>> >>>>> >>> >>>>> for >>> >>>>>> >>> >>>>>> copy/paste, POST body for WS request, etc.) >>> >>>>>> >>> >>>>>> Recently, a lot of works on the website to refresh the design (and >>> >>>> >>> >>>> logo) >>> >>>>>> >>> >>>>>> (a lot of this changes will publish on the next release) >>> >>>>>> >>> >>>>>> IMHO, the bump to JMeter 3.0, exceptionally can not only based on >>> the >>> >>>> >>> >>>> new >>> >>>>>> >>> >>>>>> behaviors since the previous version (N-1) or API changes, but we >>> >>> >>> >>> need >>> >>>> >>> >>>> to >>> >>>>>> >>> >>>>>> consider the works of all developers since 2004. (and after change >>> >>> >>> >>> to a >>> >>>>> >>> >>>>> new >>> >>>>>> >>> >>>>>> number rules) >>> >>>>>> >>> >>>>>> >>> >>>>>> Apache JMeter isn't comparable with project like Commons or >>> >>> >>> >>> HTTPClient >>> >>>> >>> >>>> on >>> >>>>>> >>> >>>>>> the versions rules. Commons/HC are mainly use as a framework >>> inside >>> >>>>> >>> >>>>> another >>> >>>>>> >>> >>>>>> software (like JMeter). JMeter is mainly use a as end user >>> software, >>> >>>> >>> >>>> the >>> >>>>>> >>> >>>>>> API (break/don't break) isn't the alone criteria to change the >>> >>> >>> >>> versions >>> >>>>>> >>> >>>>>> number. The UI and the engine must be consider to the next release >>> >>>>> >>> >>>>> number. >>> >>>>>> >>> >>>>>> Last reason to change : The users may be confused with a 2.x >>> version >>> >>>> >>> >>>> from >>> >>>>>> >>> >>>>>> 2004 (works only with Java 1.4, some jvm args are now >>> incompatibles) >>> >>>> >>> >>>> and >>> >>>>> >>> >>>>> a >>> >>>>>> >>> >>>>>> 2.14 version which require Java 7. >>> >>>>>> >>> >>>>>> >>> >>>>>> Milamber >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> On 05/01/2016 11:01, sebb wrote: >>> >>>>>> >>> >>>>>>> On 4 January 2016 at 18:23, Philippe Mouawad < >>> >>>>> >>> >>>>> philippe.moua...@gmail.com> >>> >>>>>>> >>> >>>>>>> wrote: >>> >>>>>>> >>> >>>>>>>> First Happy new year 2016 ! >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <seb...@gmail.com> wrote: >>> >>>>>>>> >>> >>>>>>>> JMeter does not have a formal policy for major/minor version >>> >>> >>> >>> release >>> >>>>>>>>> >>> >>>>>>>>> updates. >>> >>>>>>>>> However historically major veresion changes have been >>> associated >>> >>>> >>> >>>> with >>> >>>>>>>>> >>> >>>>>>>>> major changes. >>> >>>>>>>>> >>> >>>>>>>>> I am proposing to follow what seems to become a standard in >>> >>>> >>> >>>> versioning >>> >>>>>>>> >>> >>>>>>>> refering to a proposal from a scientist working on the subject. >>> >>>>>>>> >>> >>>>>>> http://semver.org/ says: >>> >>>>>>> >>> >>>>>>> Increment the MAJOR version when you make incompatible API >>> changes, >>> >>>>>>> >>> >>>>>>> We are not doing that. >>> >>>>>>> >>> >>>>>>> Also other ASF projects such as Commons and HttpClient require >>> major >>> >>>>>>>>> >>> >>>>>>>>> version bumps when removing deprecated code. >>> >>>>>>>>> >>> >>>>>>>>> So isn't this what we are doing as we dropped 4 classes >>> >>>> >>> >>>> corresponding >>> >>>>> >>> >>>>> to >>> >>>>>>>> >>> >>>>>>>> deprecated elements. And we will deprecate some more. >>> >>>>>>>> But the main idea behind this is that next version contains >>> major >>> >>>>>>>> features >>> >>>>>>>> which I think deserve this change. >>> >>>>>>>> >>> >>>>>>> What features are you referring to? >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>> I don't think the proposed changes warrant a major version bump. >>> >>>>>>>>> >>> >>>>>>>>> I don't understand, but if we don't come to an agreement I >>> propose >>> >>>> >>> >>>> to >>> >>>>>>>> >>> >>>>>>>> run a >>> >>>>>>>> vote on this although it would be better to avoid it. >>> >>>>>>>> >>> >>>>>>>> On 3 January 2016 at 15:36, Milamber <milam...@apache.org> >>> wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> I agree with a new release with a new version number system, >>> and >>> >>>> >>> >>>> with >>> >>>>>>>>>> >>> >>>>>>>>>> the >>> >>>>>>>>>> next release to become 3.0. >>> >>>>>>>>>> >>> >>>>>>>>>> Before the next release, I would like add the HiDPI (high >>> >>>> >>> >>>> definition >>> >>>>>>>>> >>> >>>>>>>>> screen) >>> >>>>>>>>> >>> >>>>>>>>>> for JMeter (for Linux Gnome/GTK and Windows). Currently I >>> works >>> >>> >>> >>> on >>> >>>>>>>>>> >>> >>>>>>>>>> this. >>> >>>>>>>>>> (my new computer have a 3200x1800 resolution on a 13' screen, >>> >>>> >>> >>>> JMeter >>> >>>>> >>> >>>>> is >>> >>>>>>>>> >>> >>>>>>>>> very >>> >>>>>>>>> >>> >>>>>>>>>> small with the CrossPlatform Swing UI) >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> On 03/01/2016 15:08, Philippe Mouawad wrote: >>> >>>>>>>>>> >>> >>>>>>>>>>> Hi Felix, >>> >>>>>>>>>>> Thanks for answer. >>> >>>>>>>>>>> I don't think it will be a long hold on the new release, for >>> me >>> >>> >>> >>> we >>> >>>>>>>>>>> >>> >>>>>>>>>>> have >>> >>>>>>>>>>> these remaining points: >>> >>>>>>>>>>> >>> >>>>>>>>>>> - Integrate HTTPCLIENT 4.5.2 to fix >>> >>>>>>>>>>> - 58583 < >>> >>>> >>> >>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58583> >>> >>>>>>>>>>> >>> >>>>>>>>>>> - 57319 >>> >>>>>>>>>>> - Finalize tests >>> >>>>>>>>>>> - 57804 => Waiting confirmation from Rainer or any >>> other >>> >>>> >>> >>>> member >>> >>>>>>>>>>> >>> >>>>>>>>>>> of >>> >>>>>>>>>>> >>> >>>>>>>>>> the >>> >>>>>>>>>> team >>> >>>>>>>>>>> >>> >>>>>>>>>>> - Deprecation: >>> >>>>>>>>>>> - 58791 => I will do it >>> >>>>>>>>>>> - Not mandatory but would be nice: >>> >>>>>>>>>>> - 58793 >>> >>>>>>>>>>> - 58790 >>> >>>>>>>>>>> - 58792 => I will try to stat it >>> >>>>>>>>>>> - 58794 => I will start a discussion on this >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> That's all for me, but if you see other things feel free to >>> add >>> >>>> >>> >>>> it. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Thanks >>> >>>>>>>>>>> >>> >>>>>>>>>>> Regards >>> >>>>>>>>>>> >>> >>>>>>>>>>> Philippe M. >>> >>>>>>>>>>> >>> >>>>>>>>>>> @philmdot >>> >>>>>>>>>>> >>> >>>>>>>>>>> On Sun, Jan 3, 2016 at 3:37 PM, Felix Schumacher < >>> >>>>>>>>>>> felix.schumac...@internetallee.de> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> Am 01.01.2016 um 19:14 schrieb Philippe Mouawad: >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Hi, >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Happy new year to the whole team. >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Any news on this ? >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> I have nothing against a 3.0, but I would not like it, if >>> the >>> >>>>> >>> >>>>> "big" >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> version change would lead to a long hold up of a new >>> release. >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Regards, >>> >>>>>>>>>>>> Felix >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> Thanks >>> >>>>>>>>>>>> >>> >>>>>>>>>>>>> On Tue, Dec 29, 2015 at 5:19 PM, Philippe Mouawad < >>> >>>>>>>>>>>>> philippe.moua...@gmail.com> wrote: >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> Hi, >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>>> Following my proposals to deprecate a certain number of >>> >>>> >>> >>>> elements >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> that >>> >>>>>>>>>>>>>> were >>> >>>>>>>>>>>>>> approved by 2 commiters and knowing that we have some >>> >>> >>> >>> important >>> >>>>> >>> >>>>> new >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> features in this release, I propose to name next version >>> 3.0 >>> >>>>>>>>>>>>>> instead >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> of >>> >>>>>>>>>> >>> >>>>>>>>>> 2.14. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> It would be the occasion to make a big cleanup in all >>> >>> >>> >>> "oldies" >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> elements >>> >>>>>>>>>> >>> >>>>>>>>>> and maybe be even more aggressive in the >>> deprecations/removals. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> And starting from there change our release naming to >>> follow >>> >>>> >>> >>>> this: >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> - http://semver.org/ >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> This has been mentioned by this thread and I think it's a >>> >>> >>> >>> good >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> idea: >>> >>>>>>>>>>>>>> - >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>> >>> >>> >>> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201411.mbox/%3CCAFJ7uesG%2BsKiQh_wQ5_iLp%3DJ%2BtSiG5fQ%3D7Pp1CvbJ1kncXo%2B%3Dg%40mail.gmail.com%3E >>> >>>>>>>>>> >>> >>>>>>>>>> I think in the developers thinking our current naming is not >>> >>> >>> >>> great, >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> cause >>> >>>>>>>>>>>>>> one can think every "major" release we do is a Minor >>> release. >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> -- >>> >>>>>>>>>>>>>> Regards >>> >>>>>>>>>>>>>> Philippe M. >>> >>>>>>>>>>>>>> @philmdot >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>> -- >>> >>>>>>>> Cordialement. >>> >>>>>>>> Philippe Mouawad. >>> >>>>>>>> >>> >>>>>>> . >>> >>>>>>> >>> >>>>>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Cordialement. >>> >>>> Philippe Mouawad. >>> >>>> >>> >> >>> >> >>> > >>> >> >> >> >> -- >> Cordialement. >> Philippe Mouawad. >> >> >> > > -- > Cordialement. > Philippe Mouawad. > > > > -- Cordialement. Philippe Mouawad.
