Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAOGo0Vb2mF2oqvauFHiA23=AgY_zKODW=zEWh0ZOigd5u8hcHw@mail.gmail.com>
References: 
 <CAH9fUpYPx25KaxXYhVt1-uQnZcyKoQYr=U4JnKJVcUB=gcdG8g@mail.gmail.com>
	<CAH9fUpbrup-AP2x3RppTmJ-R6gmQ=V7GtZudf0AZx6BKFv0rPw@mail.gmail.com>
	<5689322B.6070406@internetallee.de>
	<CAH9fUpbhe6U4naP+_XhNQnhttYHNn1MZz7Avf2i7DDqg8XZs8A@mail.gmail.com>
	<56893FF8.1050605@apache.org>
	<CAOGo0VY1mS912WVzhmP5nOgvVZs3_5V3hcj4-ZqAy2DXR2kcoQ@mail.gmail.com>
	<CAH9fUpb=J9YUke-2Q2BEFxpfWuFdYn3o+Kn=1mBLiOs9VJUCCw@mail.gmail.com>
	<CAOGo0VYV39iHKnGHrZ3oX716DyuUQ00pFL4qgXTHsDUccHMVSw@mail.gmail.com>
	<568EF94F.50708@apache.org>
	<CABWbpFfwgFvUjjm2hR2cQpCxQjxMs6AvR-NMwRnPzmLFxy48Rw@mail.gmail.com>
	<CAH9fUpaZ4--8ydfAytGBVxZjw-ce=DTgYVCN7nWW_0SQynWY=Q@mail.gmail.com>
	<CABWbpFdMzotRc3htbsTzeHQ7HWhrYY7Wgr1kbupQEx7BOYLzug@mail.gmail.com>
	<CAH9fUpaogTgqXN=6CD_RSwF3rd1nLAGuH4166tMGLBgiA1BwwA@mail.gmail.com>
	<56A4B5E1.8060305@internetallee.de>
	<CAOGo0Vb2mF2oqvauFHiA23=AgY_zKODW=zEWh0ZOigd5u8hcHw@mail.gmail.com>
Date: Mon, 25 Jan 2016 22:48:30 +0100
Message-ID: 
 <CAH9fUpa5kL9GxW=pxkuz-q7c2T3aBg_yrQ1r1AbpxDc7kQ_AGA@mail.gmail.com>
Subject: Re: Release a 3.0
From: Philippe Mouawad <philippe.mouawad@gmail.com>
To: "dev@jmeter.apache.org" <dev@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=047d7bd75860a25c2c052a2f87df

--047d7bd75860a25c2c052a2f87df
Content-Type: text/plain; charset=UTF-8

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 <sebbaz@gmail.com> wrote:

> On 24 January 2016 at 11:30, Felix Schumacher
> <felix.schumacher@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
> >> <ra0077@gmail.com>
> >> wrote:
> >>
> >>> Hi
> >>>
> >>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad <
> philippe.mouawad@gmail.com>:
> >>>
> >>>> On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues <
> >>>
> >>> ra0077@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 <milamber@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.mouawad@gmail.com>
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> First Happy new year 2016 !
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <sebbaz@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 <milamber@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.schumacher@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.mouawad@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.

--047d7bd75860a25c2c052a2f87df--