Re: [DISCUSS] Replace log4j2 with logback

[Mark Collin]

Yes there are still people using COBOL, changing that is not a case of 
upgrading a library though, so it’s really a straw man argument.

There is nothing stopping people from forking log4j and using their own fork, 
if that’s a better option for them than upgrading to a 2.x version of log4j, 
they should do that.

The problem with making an official release that fixes 1.x.x is that you are 
officially supporting it and you will be expected to support other changes.  I 
can see why the log4j team would not want to do that, it’s a waste of time and 
effort and they only have so much time to spend on (probably not paid) open 
source work.  

As you have noted fixes for 3.x and 4.x versions of JMeter would be hard 
because you use gradle to build now instead of Ant.  I would suggest that the 
time required to fix these old versions, get the build environment up and 
running again and the release config set up is probably just not worth the 
effort.  Just ask people to move to the latest version.

If you want to support obsolete versions, and have the time to do it, that’s 
totally up to you (and fair play to you).  However I would suggest that it 
would be more valuable to use that time and effort on making the current 
version better and encouraging/helping  people to stop using the obsolete stuff.

It’s a fact that nothing can be supported forever.  There comes a point where 
you have to bite the bullet and upgrade, or build something newer which is a 
better fit for current problems.



> On 21 Dec 2021, at 11:35, Vladimir Sitnikov  
> wrote:
> 
>> People have had nearly a decade
> 
> ... to remove COBOL from their apps.
> Seamless migration does not exist yet, and people have large apps that
> can't really be upgraded that easily.
> They would rather fork log4j and use their own fork.
> 
>> This is more akin to asking the JMeter team to support JMeter 2
> 
> Suppose:
> 1. someone asks to fix CVE in JMeter 1
> 2. they are eager to implement the fix
> 3. they provide a reasonable explanation why they can't upgrade
> 
> I would expect:
> a) JMeter team to implement the fix
> b) or co-operate with getting the fix released (e.g. create Git branch,
> accept PRs, etc, prepare versions).
> c) or give away control over JMeter 1 so other contributors can implement
> 1.x fixes and release 1.x versions.
> 
> For instance, option "c" might be selected by JMeter team if applying fixes
> and releasing takes too much effort.
> For example, if somebody adds GitHub Actions CI to JMeter 1.x I would be OK
> to review and merge it.
> 
> Does that answer your question?
> 
>> I would fully expect you to say move to the latest version where we have
> fixed this issue
> 
> Note that we are about to release JMeter 5.5 with new features.
> The repository is all good for the release, however, the team did
> back-patch 5.4.2
> Back-patching 5.4.2 was not my idea, and I appreciate the ones who did that
> (Milamber?)
> 
>> I wouldn’t expect you to patch JMeter 2, 3, 4, and 5.
> 
> JMeter 2 is not using log4j2, so it is not that impacted.
> We assume 5.x->5.4 upgrade is workable for everybody, and nobody voiced
> they are stuck with 5.0.
> I know people might be stuck with 4.x, and 3.x (that are affected by log4j2
> CVE), so it would be responsible
> to release those versions as well.
> 
> Unfortunately, 3.x and 4.x are Ant-based, so the release steps are way
> harder there than we have now.
> 
> Vladimir

Re: [DISCUSS] Replace log4j2 with logback

[Mark Collin]

To be fair to the log4j team, version 1.12.x went into maintenance mode back in 
2007 and they did a couple of minor updates in 2010 and 2012.

People have had nearly a decade since the last maintenance release to remove 
this old dependency and plan/implement an upgrade to the 2.x.x releases.

This is more akin to asking the JMeter team to support JMeter 2.  I would fully 
expect you to say move to the latest version where we have fixed this issue, I 
wouldn’t expect you to patch JMeter 2, 3, 4, and 5.

How long should something that is dead be supported? 

> On 21 Dec 2021, at 10:48, Vladimir Sitnikov  
> wrote:
> 
>> would you be happy
>> to see our users abandon JMeter because a CVE is discovered
>> but it can happen to any
>> project (logback also had one although less impacting)
> 
> Consider a case:
> 1. A critical vulnerability is discovered in JMeter 3.0 (e.g. remote code
> execution via HTTP client)
> 2. Multiple users report the issue and mention they can't upgrade from 3.0
> to the more recent versions and provide reasons
> 3. (optional) some users might even suggest their help or patches fix the
> issue
> 3. JMeter team says "you are using a too old version, you must upgrade;
> patches on 3.0 are not accepted anymore"
> 
> If that really happens, I expect the users would stop trusting the JMeter
> team.
> 
> 
> 
> This is exactly what happens with log4j:
> 
> 1. Critical vulnerability is discovered in log4j 1.x and 2.x
> 2. Multiple users report the issue and mention they can't upgrade from
> log4j 1.x to 2.x (too big scope of regression, incompatible configuration
> files, incompatible APIs)
> 3. Multiple users suggest patches for fixing log4j 1.x
> 4. log4j team says "you must upgrade to 2.x; patches for 1.x are not
> accepted anymore; by the way, you can't become log4j 1.x committer also"
> 
> That is a red flag to me.
> 
> I believe, the teams should either maintain the versions (e.g. keep fixing
> CVEs), or they should be open
> to give away the maintenance rights to the ones who are willing to do the
> maintenance.
> 
> It turns out, log4j team fails here. They do not allow others to touch 1.x,
> and they ignore it themselves.
> 
>> does not bring major features to users (I
>> think logging works pretty nicely today),
> 
> Of course. I expect logback to be more secure and predictable in the long
> run.
> 
> What I dislike the most is that message processing was added to log4j2 as a
> feature.
> Does that belong to a logger? Of course, not.
> 
> I expect log4j2 might get more "silent features" of that kind.
> 
> The second point is that the current set of committers for log4j team
> ignores 1.x.
> Even though I understand everybody's time is limited, they ignore
> user requests,
> and they effectively deny contributions.
> 
> See https://lists.apache.org/thread/6lhkyytvpg4md757tfydb1k0mmp5j1oc
> 
> So the key reason for getting rid of log4j is not the specific CVE.
> The key reason is I do not really trust the team behind log4j2 for the
> reasons above.
> 
> Frankly speaking, I have no idea what to do with old JMeter releases like
> 3.x, and 4.x.
> It might be very well that case we should release fixes for the past
> releases as well.
> The workaround of "replacing jars" or "cutting class files" is hard to
> maintain and control for the users.
> 
> I really fear asking Milamber to do the releases that since I expect old
> code might fail to even compile.
> However, I am sure there are a lot of users who still use JMeter 3.x.
> For instance, if JMeter 3.x features are just enough, why upgrade and get
> accidental issues?
> I can try releasing 3.x, 4.x branches though.
> 
> Vladimir

Re: Version 5.2 (Broken poms)

[Mark Collin]

Hi Vladimir,

I do take exception to the assertion that this is our fault.

As noted in that ticket you raised, the build system should have no effect on 
us.  It doesn’t matter if you build with Ant, Maven, or Gradle as long as you 
upload valid binaries and a correct POM to maven central.

Secondly we don’t use any local files, we pull binaries directly down from 
maven central using aether, so there is no point in us running a local build 
and seeing what POM files are generated, currently the plugin wouldn’t use them 
anyway.  I’m sure it’s possible to change that but to be frank I don’t have 
time (all PR’s to add this functionality gratefully accepted).  Personally I 
barely manage to keep up with bug reports that are already raised (in fact a 
lot of the time I don’t even manage that) and we really only have 2 active (and 
I’m using the word active loosely because I’m not nearly as active as I should 
be) contributors.

We are not the only consumers of the binaries that are uploaded to maven 
central and it’s really not our responsibility to make sure that you are 
uploading viable POM files and binaries, that should really be part of your 
build/test/release process.


> On 9 Nov 2019, at 11:04, Vladimir Sitnikov  
> wrote:
> 
> I reached out to jmeter-maven-plugin 3 month ago, and they did not seem to
> care: https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues/339
> 
> Vladimir

Re: Eclipse and hamcrest

[Mark Collin]

From previous experience I would suggest switching to assertj. It’s not pulled 
in by as many things so you are less likely to get wierd dependency conflicts 
and it provides useful output when things don’t match.

Also it’s a fluent api so easy to discover the various matcher methods. 

Really worth having a look at IMHO

Sent from my iPhone

> On 28 Sep 2019, at 13:51, Vladimir Sitnikov  
> wrote:
> 
> I was a bit puzzled with java-hamcrest as well.
> 
> It looks like we should exclude it: (see
> https://github.com/hamcrest/JavaHamcrest/issues/183#issuecomment-441154016
> and
> http://hamcrest.org/JavaHamcrest/distributables#upgrading-from-hamcrest-1x )
> 
> Felix, would you please check if adding org.hamcrest:hamcrest:2.1
> and org.hamcrest:hamcrest-library:2.1 solves the problem?
> 
> Vladimir

Maven issues with JMeter 3.1

[Mark Collin]

We have some maven issues again with version 3.1 of JMeter.

Can somebody have a look at these problems, it would be good to get them fixed 
for 3.2 (Or whatever the next release is).

https://bz.apache.org/bugzilla/show_bug.cgi?id=60621 
 - The report-template 
folder is missing in ApacheJMeter_config-3.1.jar in maven central
https://bz.apache.org/bugzilla/show_bug.cgi?id=60622 
 - JMeter 3.1 has 
transitive dependency issues

Re: Separate folder for 3rd-party plugins

[Mark Collin]

It doesn’t right now, but unless I’m reading the description of the PR wrong, 
it will once this 3rd party libs folder is added.

That’s a pretty big change in my mind.

> On 7 Apr 2016, at 16:25, sebb <seb...@gmail.com> wrote:
> 
> On 7 April 2016 at 12:08, Mark Collin <mark.col...@lazeryattack.com> wrote:
>> If plugins placed in the 3rd party plugins folder are added to the class 
>> path in a different order to the way they are added to the class path if we 
>> just dump them in the lib/ext folder it will have an effect.
> 
> JMeter does not guarantee any particular order of loading jars within
> the lib/ext folder; in particular the order may vary on different
> OSes.
> 
> So if the ordering is important that is *already* a potential problem.
> 
> However, the order in which jars are loaded makes a difference, it
> seems to me that this is a problem with the jars, not with JMeter.
> 
> AFAIK there's no particular ordering guaranteed with other apps such as 
> Tomcat.
> Or indeed Maven.
> 
> The solution is to ensure that there is only ever a single instance of
> each class defined in any of the jars that are loaded.
> Otherwise there will be problems at some point.
> 
>> By putting things in the wrong folder we may be changing the order they are 
>> loaded in which means that you will see different errors if you run through 
>> the plugin, or by physically putting things in the correct folder.
>> 
>>> On 6 Apr 2016, at 11:38, sebb <seb...@gmail.com> wrote:
>>> 
>>> On 6 April 2016 at 11:00, Mark Collin <mark.col...@lazeryattack.com> wrote:
>>>> I would rather see this in 3.0 than 3.1.  From the point of view of the 
>>>> jmeter-maven-plugin this is a major change because we need to change where 
>>>> we programatically put plugins as we build up a jmeter file structure on 
>>>> the disk.  From my point of view I would rather a big chance like this 
>>>> came in with a major version revision.
>>> 
>>> Huh?
>>> 
>>> AIUI this would be in *addition* to the current methods of
>>> establishing the classpath.
>>> 
>>> So it's extremely unlikely to affect your project.
>>> 
>>> If you think it will affect you, please say how, because it may affect
>>> others as well, and may affect the way it is implemented (assuming it
>>> is).
>>> 
>>>>> On 4 Apr 2016, at 12:43, Andrey Pokhilko <a...@ya.ru> wrote:
>>>>> 
>>>>> I assume "we do plugin dependencies go" is misprint for "where".
>>>>> 
>>>>> The idea is to make plugins dirs self-sufficient and, most important,
>>>>> don't touch jmeter's core "lib" and "lib/ext" dirs with plugins.
>>>>> 
>>>>> No recursive search implied, just flat list of jars in directory expected.
>>>>> 
>>>>> For example, both file of ssh-sampler plugin would be in its dir:
>>>>> 
>>>>> jmeter
>>>>> \ lib
>>>>> \ 3rdparty
>>>>>  \ ssh-sampler
>>>>>   \ ssh-sampler-1.0.jar
>>>>>   | jsh-1.2.3.jar
>>>>> 
>>>>> 
>>>>> Andrey Pokhilko
>>>>> 
>>>>> On 04/04/2016 02:37 PM, Philippe Mouawad wrote:
>>>>>> Hi Andrei,
>>>>>> With this approach, we do plugin dependencies go ?
>>>>>> 
>>>>>> Thanks
>>>>>> 
>>>>>> On Monday, April 4, 2016, Andrey Pokhilko <a...@ya.ru> wrote:
>>>>>> 
>>>>>>> I'm fine with not putting this into 3.0, if it's important for you to
>>>>>>> release it ASAP and you see a risk with this addition. I myself don't
>>>>>>> see any risks as long as change is made and reviewed carefully.
>>>>>>> 
>>>>>>> With "search_paths" property, the problem is that user has to
>>>>>>> reconfigure it for every new plugin set he installs. So instead of
>>>>>>> simplifying life for user we would complicate it. "search_paths"
>>>>>>> property implies that there's single and predictable plugins set for
>>>>>>> installation. My idea is to have directory structure agreement that
>>>>>>> allows any number of separate plugin sets from any vendors.
>>>>>>> 
>>>>>>> Andrey Pokhilko
>>>>>>> 
>>>&g

Re: Separate folder for 3rd-party plugins

[Mark Collin]

If plugins placed in the 3rd party plugins folder are added to the class path 
in a different order to the way they are added to the class path if we just 
dump them in the lib/ext folder it will have an effect.

By putting things in the wrong folder we may be changing the order they are 
loaded in which means that you will see different errors if you run through the 
plugin, or by physically putting things in the correct folder.

> On 6 Apr 2016, at 11:38, sebb <seb...@gmail.com> wrote:
> 
> On 6 April 2016 at 11:00, Mark Collin <mark.col...@lazeryattack.com> wrote:
>> I would rather see this in 3.0 than 3.1.  From the point of view of the 
>> jmeter-maven-plugin this is a major change because we need to change where 
>> we programatically put plugins as we build up a jmeter file structure on the 
>> disk.  From my point of view I would rather a big chance like this came in 
>> with a major version revision.
> 
> Huh?
> 
> AIUI this would be in *addition* to the current methods of
> establishing the classpath.
> 
> So it's extremely unlikely to affect your project.
> 
> If you think it will affect you, please say how, because it may affect
> others as well, and may affect the way it is implemented (assuming it
> is).
> 
>>> On 4 Apr 2016, at 12:43, Andrey Pokhilko <a...@ya.ru> wrote:
>>> 
>>> I assume "we do plugin dependencies go" is misprint for "where".
>>> 
>>> The idea is to make plugins dirs self-sufficient and, most important,
>>> don't touch jmeter's core "lib" and "lib/ext" dirs with plugins.
>>> 
>>> No recursive search implied, just flat list of jars in directory expected.
>>> 
>>> For example, both file of ssh-sampler plugin would be in its dir:
>>> 
>>> jmeter
>>> \ lib
>>>  \ 3rdparty
>>>   \ ssh-sampler
>>>\ ssh-sampler-1.0.jar
>>>| jsh-1.2.3.jar
>>> 
>>> 
>>> Andrey Pokhilko
>>> 
>>> On 04/04/2016 02:37 PM, Philippe Mouawad wrote:
>>>> Hi Andrei,
>>>> With this approach, we do plugin dependencies go ?
>>>> 
>>>> Thanks
>>>> 
>>>> On Monday, April 4, 2016, Andrey Pokhilko <a...@ya.ru> wrote:
>>>> 
>>>>> I'm fine with not putting this into 3.0, if it's important for you to
>>>>> release it ASAP and you see a risk with this addition. I myself don't
>>>>> see any risks as long as change is made and reviewed carefully.
>>>>> 
>>>>> With "search_paths" property, the problem is that user has to
>>>>> reconfigure it for every new plugin set he installs. So instead of
>>>>> simplifying life for user we would complicate it. "search_paths"
>>>>> property implies that there's single and predictable plugins set for
>>>>> installation. My idea is to have directory structure agreement that
>>>>> allows any number of separate plugin sets from any vendors.
>>>>> 
>>>>> Andrey Pokhilko
>>>>> 
>>>>> On 04/04/2016 02:24 PM, Philippe Mouawad wrote:
>>>>>> Hi,
>>>>>> 3.0 is very close to release, I suggest we freeze new dev now and release
>>>>>> it.
>>>>>> I have been asked tens of time when it's out.
>>>>>> This can be done in 3.1
>>>>>> 
>>>>>> For info, this can already be done currently with search_paths property
>>>>> and
>>>>>> user.classpath one.
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> On Monday, April 4, 2016, Refael Botbol <ref...@blazemeter.com
>>>>> <javascript:;>> wrote:
>>>>>>> I'm using lots of 3rd party plugins with JMeter and to me it will make
>>>>> life
>>>>>>> much easier because:
>>>>>>> 
>>>>>>>  1. If i'm installing a new plugin which crashes - i can uninstall it
>>>>>>>  quickly.
>>>>>>>  2. It will give a clear list of which plugins I'm currently using
>>>>> incase
>>>>>>>  I need to run my script on a different machine
>>>>>>>  3. Upgrading JMeter to a newer version will be almost seamless (just
>>>>>>>  updating the path to my 3rd party plugin..) that way I don't need to
>>>>>>>  duplicate every plugin across multiple JMeter versions I have
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Apr 4, 2016 at 1:47 PM Andrey Pokhilko <a...@ya.ru
>>>>> <javascript:;> <javascript:;>>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> No, I don't mean OSGification. I mean just classpath building.
>>>>>>>> 
>>>>>>>> In case of library clash the earlier entry in classpath will win. At
>>>>>>>> least, there will be easy way to understand which plugins set brings
>>>>>>>> which library and reveal the plugins conflicts. For now, all guavas go
>>>>>>>> into "lib" and you look at it with no idea "why did it happen and how
>>>>> to
>>>>>>>> go out of it".
>>>>>>>> 
>>>>>>>> Andrey Pokhilko
>>>>>>>> 
>>>>>>>> On 04/04/2016 01:34 PM, Vladimir Sitnikov wrote:
>>>>>>>>> Do you mean some kind of OSGification?
>>>>>>>>> 
>>>>>>>>> What if different 3rdparties try to include different versions of,
>>>>> say,
>>>>>>>> guava?
>>>>>>>>> Which version will ultimately be loaded in your suggested approach?
>>>>>>>>> 
>>>>>>>>> Vladimir
>>>>>>>> --
>>>>>>> Refael Botbol, BlazeMeter.
>>>>>>> Director of Professional Services
>>>>>>> 
>>>>> 
>>> 
>> 

Re: Separate folder for 3rd-party plugins

[Mark Collin]

I would rather see this in 3.0 than 3.1.  From the point of view of the 
jmeter-maven-plugin this is a major change because we need to change where we 
programatically put plugins as we build up a jmeter file structure on the disk. 
 From my point of view I would rather a big chance like this came in with a 
major version revision.

> On 4 Apr 2016, at 12:43, Andrey Pokhilko  wrote:
> 
> I assume "we do plugin dependencies go" is misprint for "where".
> 
> The idea is to make plugins dirs self-sufficient and, most important,
> don't touch jmeter's core "lib" and "lib/ext" dirs with plugins.
> 
> No recursive search implied, just flat list of jars in directory expected.
> 
> For example, both file of ssh-sampler plugin would be in its dir:
> 
> jmeter
>  \ lib
>   \ 3rdparty
>\ ssh-sampler
> \ ssh-sampler-1.0.jar
> | jsh-1.2.3.jar
> 
> 
> Andrey Pokhilko
> 
> On 04/04/2016 02:37 PM, Philippe Mouawad wrote:
>> Hi Andrei,
>> With this approach, we do plugin dependencies go ?
>> 
>> Thanks
>> 
>> On Monday, April 4, 2016, Andrey Pokhilko  wrote:
>> 
>>> I'm fine with not putting this into 3.0, if it's important for you to
>>> release it ASAP and you see a risk with this addition. I myself don't
>>> see any risks as long as change is made and reviewed carefully.
>>> 
>>> With "search_paths" property, the problem is that user has to
>>> reconfigure it for every new plugin set he installs. So instead of
>>> simplifying life for user we would complicate it. "search_paths"
>>> property implies that there's single and predictable plugins set for
>>> installation. My idea is to have directory structure agreement that
>>> allows any number of separate plugin sets from any vendors.
>>> 
>>> Andrey Pokhilko
>>> 
>>> On 04/04/2016 02:24 PM, Philippe Mouawad wrote:
 Hi,
 3.0 is very close to release, I suggest we freeze new dev now and release
 it.
 I have been asked tens of time when it's out.
 This can be done in 3.1
 
 For info, this can already be done currently with search_paths property
>>> and
 user.classpath one.
 
 Regards
 
 On Monday, April 4, 2016, Refael Botbol >> > wrote:
> I'm using lots of 3rd party plugins with JMeter and to me it will make
>>> life
> much easier because:
> 
>   1. If i'm installing a new plugin which crashes - i can uninstall it
>   quickly.
>   2. It will give a clear list of which plugins I'm currently using
>>> incase
>   I need to run my script on a different machine
>   3. Upgrading JMeter to a newer version will be almost seamless (just
>   updating the path to my 3rd party plugin..) that way I don't need to
>   duplicate every plugin across multiple JMeter versions I have
> 
> 
> 
> On Mon, Apr 4, 2016 at 1:47 PM Andrey Pokhilko >>  >
> wrote:
> 
>> No, I don't mean OSGification. I mean just classpath building.
>> 
>> In case of library clash the earlier entry in classpath will win. At
>> least, there will be easy way to understand which plugins set brings
>> which library and reveal the plugins conflicts. For now, all guavas go
>> into "lib" and you look at it with no idea "why did it happen and how
>>> to
>> go out of it".
>> 
>> Andrey Pokhilko
>> 
>> On 04/04/2016 01:34 PM, Vladimir Sitnikov wrote:
>>> Do you mean some kind of OSGification?
>>> 
>>> What if different 3rdparties try to include different versions of,
>>> say,
>> guava?
>>> Which version will ultimately be loaded in your suggested approach?
>>> 
>>> Vladimir
>> --
> Refael Botbol, BlazeMeter.
> Director of Professional Services
> 
>>> 
> 

Re: Remaining Work before Release of 3.0

[Mark Collin]

> If Mark is ok with this, what about having a separate sister project of
> jmeter for the maven plugin (maybe also the jenkins one if we have some
> volunteers)
> It could be (if incubated and agreed upon) under the Apache umbrella and we
> could(those who want) participate to it.
> 
> The release process would be partly dependant on jmeter but as sebb wrote
> also on maven /jenkins.
> 


Not sure I understand what you are proposing here?  A sister version of Jmeter 
using Maven as a build tool?  That seems like an awful lot of work for very 
little gain.

Or are you suggesting moving the maven-plugin under the Apache umbrella?

Re: Remaining Work before Release of 3.0

[Mark Collin]

If the JMeter devs want to put it in core I have no issue with that, however 
the plugin is a maven project an I don’t think maven projects are wanted in 
JMeter core :)

The website is down at the moment, it’s in the process of being moved over to 
github.io. (I should probably update the README to note that)

> On 4 Mar 2016, at 09:51, Antonio Gomes Rodrigues <ra0...@gmail.com> wrote:
> 
> Hi Mark,
> 
> I don't have problem with JMeter-Maven-Plugin (and your documentation
> rocks) in particularity
> 
> It's only my experience with third party plugin in general and project with
> only one developer.
> And this experience is not always good and it's why I don't like to advise
> my customer to use these projects/plugins
> 
> One question, why don't integrate officially your plugin to JMeter core?
> 
> About your website, I have a timeout :-(
> 
> Thanks to your feedback
> 
> Antonio
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Cet e-mail a été envoyé depuis un ordinateur protégé par Avast.
> www.avast.com
> <https://www.avast.com/fr-fr/lp-esg-win-01a?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=OA-2109-C>
> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> 2016-03-04 9:29 GMT+01:00 Mark Collin <mark.col...@lazeryattack.com>:
> 
>> 
>>>>> Lack of official feature (JMeter plugin, Maven plugin, etc.)
>>>> 
>>>> 
>>>> non official maven plugin exists and works rather nicely.
>>>> What do you mean by JMeter plugin ?
>>>> 
>>> 
>>> In general I have very bad experience with:
>>> third party plugin (not well integrate, not well tested, not up to date
>>> with the latest release, etc.)
>>> Plugin maintained by only one person (less motivation by the developer,
>>> etc.)
>> 
>> Bug fixes for the maven plugin are happily accepted.  Also please add
>> issues for things that are:
>> Not well integrated
>> Not well tested
>> Not up to date
>> So that we can fix them (
>> https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues).
>> 
>> In regards to it being up to date:
>> The plugin didn’t support JMeter 2.12 Because there were transitive
>> dependency issues with the 2.12 maven release.
>> There were also transitive dependency issues with the JMeter 2.13 release
>> that we tried to work around.  Version 1.10.1 of the plugin does use JMeter
>> 2.13.
>> Is there something else we have missed which makes you say it’s not up to
>> date (Feedback is the only way we can make it better)?
>> 
>> We are planning a version 2.0.0 of the plugin to coincide with a 3.0
>> JMeter release.  The 2.0.0-SNAPSHOT is available in the Sonatype snapshots
>> repository if you want to try it out and provide some feedback so that we
>> can make it better that would be really useful.

Re: Remaining Work before Release of 3.0

[Mark Collin]

>>> Lack of official feature (JMeter plugin, Maven plugin, etc.)
>> 
>> 
>> non official maven plugin exists and works rather nicely.
>> What do you mean by JMeter plugin ?
>> 
> 
> In general I have very bad experience with:
> third party plugin (not well integrate, not well tested, not up to date
> with the latest release, etc.)
> Plugin maintained by only one person (less motivation by the developer,
> etc.)

Bug fixes for the maven plugin are happily accepted.  Also please add issues 
for things that are:
Not well integrated
Not well tested
Not up to date
So that we can fix them 
(https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues).

In regards to it being up to date:
The plugin didn’t support JMeter 2.12 Because there were transitive dependency 
issues with the 2.12 maven release.
There were also transitive dependency issues with the JMeter 2.13 release that 
we tried to work around.  Version 1.10.1 of the plugin does use JMeter 2.13.
Is there something else we have missed which makes you say it’s not up to date 
(Feedback is the only way we can make it better)?

We are planning a version 2.0.0 of the plugin to coincide with a 3.0 JMeter 
release.  The 2.0.0-SNAPSHOT is available in the Sonatype snapshots repository 
if you want to try it out and provide some feedback so that we can make it 
better that would be really useful.

JMeter 2.12 Transitive Dependency Issues

[Mark Collin]

Just a quick heads up about this bug

https://bz.apache.org/bugzilla/show_bug.cgi?id=57649

It would be good to have a test that checks to see if there are any transitive 
dependency issues in maven after the POMs are built.

Re: Missing dependency in 2.11

[Mark Collin]

I’ll go hassle them then :)

On 15 Jan 2014, at 20:37, Philippe Mouawad philippe.moua...@gmail.com wrote:

 Hello Mark,
 See:
 
   - https://github.com/bobbylight/RSyntaxTextArea/issues/20
 
 
 This is not under our control, within JMeter we download zip from
 http://downloads.sourceforge.net/project/rsyntaxtextarea/rsyntaxtextarea/and
 extract jar.
 
 Regards
 
 Philippe M.
 
 
 On Wed, Jan 15, 2014 at 8:34 PM, Mark Collin
 mark.col...@lazeryattack.comwrote:
 
 Just a quick one to make you aware, I’m getting the following as a missing
 maven dependency in maven central for JMeter 2.11:
 
 Downloading:
 http://repo.maven.apache.org/maven2/com/fifesoft/rsyntaxtextarea/2.5.1/rsyntaxtextarea-2.5.1.pom
 Downloading:
 https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/com/fifesoft/rsyntaxtextarea/2.5.1/rsyntaxtextarea-2.5.1.pom
 [WARNING] The POM for com.fifesoft:rsyntaxtextarea:jar:2.5.1 is missing,
 no dependency information available
 Downloading:
 http://repo.maven.apache.org/maven2/com/fifesoft/rsyntaxtextarea/2.5.1/rsyntaxtextarea-2.5.1.jar
 Downloading:
 https://repository.jboss.org/nexus/content/repositories/thirdparty-releases/com/fifesoft/rsyntaxtextarea/2.5.1/rsyntaxtextarea-2.5.1.jar
 
 
 
 
 
 -- 
 Cordialement.
 Philippe Mouawad.

Re: ApacheJMeter_mongodb is missing from maven central

[Mark Collin]

I have now :)

Thanks for keeping me up to date.

On 12 Jan 2014, at 09:33, Philippe Mouawad philippe.moua...@gmail.com wrote:

 Hello,
 You probably have seen vote started, if not ETA should be around 72 hours +
 few more hours for ending operations.
 
 Thanks to RM milamber !
 
 Regards
 
 On Saturday, January 11, 2014, Mark Collin wrote:
 
 Do you have a rough ETA for getting the 2.10 and 2.11 ApacheJMeter_mongodb
 jars up in maven central?
 
 I have a new release of the jmeter-maven-plugin ready to go and I’m trying
 to decide whether to wait for the jar to be in maven central, or just mark
 the missing jar as a known problem with a workaround for when it is
 available.
 
 
 On 8 Jan 2014, at 00:22, sebb seb...@gmail.com javascript:; wrote:
 
 On 8 January 2014 00:09, Milamber milam...@apache.org javascript:;
 wrote:
 Hello,
 
 Thanks for report. I've fixed this for next release.
 
 @Sebb, what is the best way to upload the mongo maven package ?
 
 I don't know if it's possible to add extra jars to an existing release or
 not.
 I suggest you ask on the Maven user list.
 
 Note: since the pom is source, we probably ought to vote on the updates

Re: ApacheJMeter_mongodb is missing from maven central

[Mark Collin]

Do you have a rough ETA for getting the 2.10 and 2.11 ApacheJMeter_mongodb jars 
up in maven central?

I have a new release of the jmeter-maven-plugin ready to go and I’m trying to 
decide whether to wait for the jar to be in maven central, or just mark the 
missing jar as a known problem with a workaround for when it is available.


On 8 Jan 2014, at 00:22, sebb seb...@gmail.com wrote:

 On 8 January 2014 00:09, Milamber milam...@apache.org wrote:
 Hello,
 
 Thanks for report. I've fixed this for next release.
 
 @Sebb, what is the best way to upload the mongo maven package ?
 
 I don't know if it's possible to add extra jars to an existing release or
 not.
 I suggest you ask on the Maven user list.
 
 Note: since the pom is source, we probably ought to vote on the updates.
 Also we should ensure that the jars in the release are copies of the
 ones in the binary archive, rather than rebuilds.
 
 Since all write access to Maven Central is via Nexus, and Nexus can
 only hold one staging area for each GA pair, this will have to be done
 in two stages.
 i.e. upload 2.10 (somehow), vote, promote
 then repeat for 2.11
 
 Milamber
 
 
 Le 07/01/2014 10:54, Mark Collin a ecrit :
 
 I’ve logged this as:
 
 https://issues.apache.org/bugzilla/show_bug.cgi?id=55965
 
 
 On 7 Jan 2014, at 10:47, Mark Collin mark.col...@lazeryattack.com
 wrote:
 
 Just been going through the dependencies in maven central today and
 I’ve
 noticed that ApacheJMeter_mongodb is missing for 2.10 and 2.11.
 
 Can these be uploaded?
 
 
 

Re: ApacheJMeter_mongodb is missing from maven central

[Mark Collin]

I’ve logged this as:

https://issues.apache.org/bugzilla/show_bug.cgi?id=55965


 On 7 Jan 2014, at 10:47, Mark Collin mark.col...@lazeryattack.com wrote:
 
 Just been going through the dependencies in maven central today and I’ve 
 noticed that ApacheJMeter_mongodb is missing for 2.10 and 2.11.
 
 Can these be uploaded?

RE: Wiki Access Request

[Mark Collin]

Ardesco

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 12 March 2013 18:51
To: dev@jmeter.apache.org
Subject: Re: Wiki Access Request

On 12 March 2013 12:22, Mark Collin mark.col...@lazeryattack.com wrote:
 Can I get access to the wiki to update the 
 http://wiki.apache.org/jmeter/JMeterMavenPlugin page?


Yes - what is your Wiki login name?


 The information currently shown is quite out of date.

RE: Wiki Access Request

[Mark Collin]

thanks

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 12 March 2013 19:11
To: dev@jmeter.apache.org
Subject: Re: Wiki Access Request

Done

On 12 March 2013 19:06, Mark Collin mark.col...@lazeryattack.com wrote:
 Ardesco

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 12 March 2013 18:51
 To: dev@jmeter.apache.org
 Subject: Re: Wiki Access Request

 On 12 March 2013 12:22, Mark Collin mark.col...@lazeryattack.com wrote:
 Can I get access to the wiki to update the 
 http://wiki.apache.org/jmeter/JMeterMavenPlugin page?


 Yes - what is your Wiki login name?


 The information currently shown is quite out of date.

What is the preffered way to detect that a test has ended and cleanup has completed?

[Mark Collin]

This is causing me a few issues.

 

I've tried adding a test listener which detects the end of the test, the
problem is that I don't know when clean-up has completed and things like the
reporting listener have completed their job(s).

 

I am currently doing the following:

 

1.   Wait for a test end to be reported to the test listener.

2.   Wait for a period of jmeter.exit.check.pause + 5000ms (The pause
hard coded in Jmeter for listener cleanup) + 500ms (extra pause to provide
an error margin).

 

Unfortunately I still seem to be continuing before the .jtl files have
finished being written intermittently.

 

I could scan the JMeter log file and wait until it reports the end of the
test, but this is really not a very nice solution IMHO.  Is anything
triggered after JMeter has completed clean up and written the .jtl logs that
I can hook a listener into that I have missed?

RE: What is the preffered way to detect that a test has ended and cleanup has completed?

[Mark Collin]

I'm trying to programmatically determine that a test has finished before
processing the JMeter logs.

The test listener I create tells me that a test has finished, but I need to
wait for clean-up to complete so that the listener that writes to the .jtl
file has finished what it's doing.


-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 19 March 2012 12:39
To: dev@jmeter.apache.org
Subject: Re: What is the preffered way to detect that a test has ended and
cleanup has completed?

On 19 March 2012 11:52, Mark Collin mark.col...@lazeryattack.com wrote:
 This is causing me a few issues.



 I've tried adding a test listener which detects the end of the test, 
 the problem is that I don't know when clean-up has completed and 
 things like the reporting listener have completed their job(s).


What are you trying to achieve?


 I am currently doing the following:



 1.       Wait for a test end to be reported to the test listener.

 2.       Wait for a period of jmeter.exit.check.pause + 5000ms (The 
 pause hard coded in Jmeter for listener cleanup) + 500ms (extra pause 
 to provide an error margin).



 Unfortunately I still seem to be continuing before the .jtl files have 
 finished being written intermittently.



 I could scan the JMeter log file and wait until it reports the end of 
 the test, but this is really not a very nice solution IMHO.  Is 
 anything triggered after JMeter has completed clean up and written the 
 .jtl logs that I can hook a listener into that I have missed?

JMeter non-GUI will exit.

Beanshell and Maven

[Mark Collin]

I've been spending some time trying to get the JMeter dependencies that are
not currently available in maven central added because a lot of corporate
maven proxies (e.g. artifactory) are configured to only download packages
from maven central.

 

For a package to be moved into maven central it needs to have the sources
and javadocs bundled with it as well (at least when trying to get packages
pushed up using sonatypes oss service, it does). 

 

I've managed to get jCharts 0.7.5 added and it is now available in maven
central, however I'm having real problems with the missing beanshell
dependency.

 

The problems I'm facing:

 

. The current beanshell packages on third party maven repos do not
have either sources or javadocs.

. I am unable to find any active developers for beanshell.

. I am unable to find the source code that so I can package it up as
a sources jar and create a javadocs jar from the source.

. I am having real problems finding an official 2.0b5 package which
includes source and javadocs.

 

There is a 2.0b5 package available in some third party maven repo's and you
can download a copy of the 2.0b5 jar from the http://www.beanshell.org/
website, but there is no mention of 2.0b5 anywhere on the site and the
mailing lists have been dead for years.

 

With all of this in mind it looks like there is no way to get beanshell
pushed into maven central (unless you know of a repo somewhere that has the
missing parts).

 

So down to my questions:

 

1.   What would be the consequences of using bsh-2.0b4 instead of b5?  I
could set this as a dependency for the maven plugin I'm working on so that
if a local cache can't download from a third party repo an older version is
available.

2.   Have you considered updating beanshell to the beanshell 2 fork that
is currently active and being developed upon
(http://code.google.com/p/beanshell2/)?  It may be much easier to convince
an active project to make a maven release of their code.

 

 

RE: Beanshell and Maven

[Mark Collin]

I found the sources this morning \o/

Trying to get this uploaded to maven central now as well.

-Original Message-
From: Mark Collin [mailto:mark.col...@lazeryattack.com] 
Sent: 16 March 2012 06:34
To: dev@jmeter.apache.org
Subject: Beanshell and Maven

I've been spending some time trying to get the JMeter dependencies that are
not currently available in maven central added because a lot of corporate
maven proxies (e.g. artifactory) are configured to only download packages
from maven central.

 

For a package to be moved into maven central it needs to have the sources
and javadocs bundled with it as well (at least when trying to get packages
pushed up using sonatypes oss service, it does). 

 

I've managed to get jCharts 0.7.5 added and it is now available in maven
central, however I'm having real problems with the missing beanshell
dependency.

 

The problems I'm facing:

 

. The current beanshell packages on third party maven repos do not
have either sources or javadocs.

. I am unable to find any active developers for beanshell.

. I am unable to find the source code that so I can package it up as
a sources jar and create a javadocs jar from the source.

. I am having real problems finding an official 2.0b5 package which
includes source and javadocs.

 

There is a 2.0b5 package available in some third party maven repo's and you
can download a copy of the 2.0b5 jar from the http://www.beanshell.org/
website, but there is no mention of 2.0b5 anywhere on the site and the
mailing lists have been dead for years.

 

With all of this in mind it looks like there is no way to get beanshell
pushed into maven central (unless you know of a repo somewhere that has the
missing parts).

 

So down to my questions:

 

1.   What would be the consequences of using bsh-2.0b4 instead of b5?  I
could set this as a dependency for the maven plugin I'm working on so that
if a local cache can't download from a third party repo an older version is
available.

2.   Have you considered updating beanshell to the beanshell 2 fork that
is currently active and being developed upon
(http://code.google.com/p/beanshell2/)?  It may be much easier to convince
an active project to make a maven release of their code.

 

 

RE: Maven Snapshots

[Mark Collin]

Excellent, this will be very useful for us, thanks :).

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 29 February 2012 12:28
To: dev@jmeter.apache.org
Subject: Re: Maven Snapshots

I've updated the buildbot nightly build, and it should upload to the
snaphots repo:

https://repository.apache.org/content/repositories/snapshots/

The SVN revision is stored in the jar manifests as follows

Implementation-Version: r1294940

No guarantee that the jars will work.

I don't know if the jars will be uploaded if the unit tests fail; I suspect
the test status is ignored.

On 28 February 2012 11:22, Philippe Mouawad philippe.moua...@gmail.com
wrote:
 Hello,
 From what I know sebb is working on the issue.

 Regards
 Philippe

 On Tue, Feb 28, 2012 at 12:03 PM, Mark Collin
m...@ardescosolutions.comwrote:

 Going to bump this one more time in the hope of getting an answer.

 -Original Message-
 From: Mark Collin [mailto:m...@ardescosolutions.com]
 Sent: 17 February 2012 16:40
 To: dev@jmeter.apache.org
 Subject: RE: Maven Snapshots

 Not heard anything back on this, is it a possibility?

 -Original Message-
 From: Mark Collin [mailto:m...@ardescosolutions.com]
 Sent: 13 February 2012 22:47
 To: dev@jmeter.apache.org
 Subject: Maven Snapshots

 Would it be possible to set the build server up to deploy maven 
 snapshots on a successful build?



 This will enable us to run a nightly build of our maven plugin 
 against the current snapshot to see if anything you have done breaks what
we have done.
 Not essential, but it could be very useful J




 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com
 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com




 --
 Cordialement.
 Philippe Mouawad.

--
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received

RE: Maven Snapshots

[Mark Collin]

Thanks for the reply :)


-Original Message-
From: Philippe Mouawad [mailto:philippe.moua...@gmail.com] 
Sent: 28 February 2012 11:22
To: dev@jmeter.apache.org
Subject: Re: Maven Snapshots

Hello,
From what I know sebb is working on the issue.

Regards
Philippe

On Tue, Feb 28, 2012 at 12:03 PM, Mark Collin
m...@ardescosolutions.comwrote:

 Going to bump this one more time in the hope of getting an answer.

 -Original Message-
 From: Mark Collin [mailto:m...@ardescosolutions.com]
 Sent: 17 February 2012 16:40
 To: dev@jmeter.apache.org
 Subject: RE: Maven Snapshots

 Not heard anything back on this, is it a possibility?

 -Original Message-
 From: Mark Collin [mailto:m...@ardescosolutions.com]
 Sent: 13 February 2012 22:47
 To: dev@jmeter.apache.org
 Subject: Maven Snapshots

 Would it be possible to set the build server up to deploy maven 
 snapshots on a successful build?



 This will enable us to run a nightly build of our maven plugin against 
 the current snapshot to see if anything you have done breaks what we have
done.
 Not essential, but it could be very useful J




 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com
 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

 --
 This message contains confidential information and is intended only 
 for the individual named. If you are not the named addressee you 
 should not disseminate, distribute or copy this e-mail. Please notify 
 the sender immediately by e-mail if you have received this e-mail by 
 mistake and delete this e-mail from your system. If you are not the 
 intended recipient you are notified that disclosing, copying, 
 distributing or taking any action in reliance on the contents of this 
 information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com




--
Cordialement.
Philippe Mouawad.

--
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify 
postmas...@ardescosolutions.com

RE: [Incorrect Link] RE: [ANNOUNCE] JMeter 2.6 is released

[Mark Collin]

Woohoo :)

Is that going to get pushed up to central?

-Original Message-
From: Milamber [mailto:milam...@apache.org] 
Sent: 02 February 2012 12:12
To: dev@jmeter.apache.org
Subject: Re: [Incorrect Link] RE: [ANNOUNCE] JMeter 2.6 is released



Le 02/02/2012 09:23, Mark Collin a ecrit :
 Is there an eta for a maven release?
   

Maven release repo is accessible here:
https://repository.apache.org/content/repositories/releases/org/apache/jmeter/




 -Original Message-
 From: Milamber [mailto:milam...@apache.org]
 Sent: 02 February 2012 07:12
 To: Franklin, Matthew B.
 Cc: 'JMeter Dev List'
 Subject: Re: [Incorrect Link] RE: [ANNOUNCE] JMeter 2.6 is released



 Le 02/02/2012 00:37, Franklin, Matthew B. a ecrit :
   
 FYI - the link to changes is incorrect. docs is in the path when it 
 shouldn't be and people will get a 404 when it is clicked.
 
 Yes, that is a mistake in my email. It's corrected now with a html 
 redirection to the good url.

 Milamber

   


 Sent via a mobile device. Please excuse typos or brevity.

 -Original Message-
 *From: *Milamber [milam...@apache.org mailto:milam...@apache.org]
 *Sent: *Wednesday, February 01, 2012 06:29 PM Eastern Standard Time
 *To: *JMeter Dev List; JMeter Users List
 *Cc: *annou...@apache.org
 *Subject: *[ANNOUNCE] JMeter 2.6 is released

 The Apache JMeter team announces the availability of Apache JMeter 
 2.6 r1237316.

 This release brings some valuable improvements and fixes some bugs.

 New and Noteworthy with some screenshots to illustrate improvements 
 and list of changes can be found at:
 http://jmeter.apache.org/docs/changes.html

 JMeter 2.6 requires Java 1.5 or later to run.

 == All users are recommended to upgrade. ==

 Apache JMeter is a Java application designed to test server applications.
 It can be used to:
 * generate test loads
 * test functional behavior
 * measure performance.
 It includes support for protocols such as HTTP(S), JDBC, JMS, FTP, 
 and others.
 It can also be extended with user-written code.

 See http://jmeter.apache.org/

 The release can be downloaded from:
 http://jmeter.apache.org/download_jmeter.cgi

 When downloading, please verify signatures using the KEYS file.

 Only the binary archive is needed to run JMeter - there is no need to 
 download the source archive.

 However there are some optional libraries which are not included.
 See the Getting Started page for details:
 http://jmeter.apache.org/usermanual/get-started.html

 Enjoy!
 The JMeter team


 -
 To unsubscribe, e-mail: announce-unsubscr...@apache.org For 
 additional commands, e-mail: announce-h...@apache.org


 

 --
 This message contains confidential information and is intended only for the 
 individual named. If you are not the named addressee you should not 
 disseminate, distribute or copy this e-mail. Please notify the sender 
 immediately by e-mail if you have received this e-mail by mistake and delete 
 this e-mail from your system. If you are not the intended recipient you are 
 notified that disclosing, copying, distributing or taking any action in 
 reliance on the contents of this information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

   


--
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify 
postmas...@ardescosolutions.com

RE: Properties files in mavenised artifacts

[Mark Collin]

Unfortunately that's what it looks like :(

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 23 January 2012 13:46
To: dev@jmeter.apache.org
Subject: Re: Properties files in mavenised artifacts

On 23 January 2012 13:08, Mark Collin m...@ardescosolutions.com wrote:
 Yes parent really does have to be a POM package.

Bother.

So we need another jar and another pom.

 http://maven.apache.org/guides/introduction/introduction-to-the-pom.ht
 ml

 I've just tried using the latest 2.6-SNAPSHOT and I'm getting the 
 following
 error:

How are you using it?

 [INFO]
 --
 --
 [ERROR] BUILD ERROR
 [INFO]
 --
 -- [INFO] Error building POM (may not be this project's POM).


 Project ID: org.apache.jmeter:ApacheJMeter_core

 Reason: Parent: org.apache.jmeter:ApacheJMeter_parent:jar:2.6-SNAPSHOT 
 of
 project: org.apache.jmeter:ApacheJMeter_core has wrong packaging: jar. 
 Must be 'pom'. for project org.apache.jmeter:ApacheJMeter_core


 [INFO]
 --
 -- [INFO] For more information, run Maven with the -e switch [INFO]
 --
 --
 [INFO] Total time: 12 seconds
 [INFO] Finished at: Mon Jan 23 13:03:50 GMT 2012 [INFO] Final Memory: 
 13M/107M [INFO]
 --
 --

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 23 January 2012 12:15
 To: dev@jmeter.apache.org
 Subject: Re: Properties files in mavenised artifacts

 On 23 January 2012 12:03, Mark Collin m...@ardescosolutions.com wrote:
 Thinking about it, I think I'm talking a degree of rubbish here.

 A parent needs to be packaged as a pom and not a jar so even if you 
 add a build section it's not going to work.  I think you will instead 
 need to have a new package that the parent depends on that pulls in 
 these
 extra files.

 Currently, the parent is now a jar package which contains the 
 configuration files.

 The poms are basically just being used as jar descriptors and 
 dependency declarations currently.

 Does the parent really have to be a pom package?

 Has anyone tried using one of the latest snapshots (i.e. one with 
 ApacheJMeter_parent.jar as well as .pom)?

 -Original Message-
 From: Mark Collin [mailto:m...@ardescosolutions.com]
 Sent: 23 January 2012 06:39
 To: dev@jmeter.apache.org
 Subject: RE: Properties files in mavenised artifacts

 The mvn deploy command should also build the package if the build 
 section exists in the POM so you could have a build section for the 
 parent POM that only pulls in resources that are required (this would 
 muddy the waters slightly but seems like the pragmatic approach).

 Of course you could also tweak your ant script to build all of the 
 dependencies into a jar and then deploy that as well for the 
 mavenised build.  This sounds worse IMHO because you are modifying 
 your existing build process to create something that your normal ant 
 build doesn't
 require.

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 23 January 2012 01:50
 To: dev@jmeter.apache.org
 Subject: Re: Properties files in mavenised artifacts

 On 23 January 2012 01:03, sebb seb...@gmail.com wrote:
 On 22 January 2012 18:21, Mark Collin m...@ardescosolutions.com wrote:
 Parent sounds like a good place.

 Normally it would pick up things in src/main/resources, but as you 
 don't have a maven directory structure I think you'll need to 
 define a resource dir in the parent POM.  Something like this should
work:

 resources
    resource
        directory${basedir}/bin/directory
        includes
            include**/*.properties/include
        /includes
    /resource
 /resources

 OK, thanks, I'll try that.

 Just realised that won't work for creating the files to be uploaded, 
 as we don't use Maven to create the artifacts.

 I'm not sure exactly where you would need to place it in the 
 artifact, I guess that depends on where you expect them to be when 
 you
 read them in.

 JMeter expects to find them in the bin/ directory, i.e. where it 
 finds ApacheJMeter.jar.

 However, I've no idea how any JMeter Maven launch plugins are 
 intended to work so that may not be appropriate.

 Sorry, but I've no idea how to make this work.

 All I can suggest is creating a jar containing the missing properties 
 files (there are also some other missing files) which can be uploaded 
 as
 parent

 --
 This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you

Properties files in mavenised artifacts

[Mark Collin]

I've been hunting through the mavenised artifacts available at:

 

https://repository.apache.org/content/repositories/snapshots/org/apache/jmet
er/

 

However I cannot find the following in any package:

 

saveservice.properties

upgrade.properties

system.properties

jmeter.properties

user.properties

 

If I'm being blind please point me in the right direction, if I'm not being
blind can we get these added to an artefact, or another artefact added that
contains these.

 

--

Mark Collin

Managing Director

Ardesco Solutions Ltd

 

 mailto:m...@ardescosolutions.com m...@ardescosolutions.com

 

Registered Office:

The Coachhouse

Greys Green Business Centre

Henley-on-Thames

Oxon

RG9 4QG

 

REGISTERED IN ENGLAND NO. 4837759

 


--
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify 
postmas...@ardescosolutions.com

RE: Publishing to Maven Central

[Mark Collin]

 Mark

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 18 January 2012 23:39
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central

 On 18 January 2012 22:45, Mark Collin m...@ardescosolutions.com wrote:
 Uploaded a final version just now.

 I had to fix some transitive dependency problems that were not
 apparent until you tried to use the artifacts and I had one POM that
 was not correctly referencing ApacheJMeter_parent.

 The final version will also automatically download ant-contrib if you
 don't have it to make the whole process easier.

 I don't think we need the ant-contrib; so long as Maven is locally
 installed
 it's possible to access it using Java.

 I recently committed an Ant script that uses this technique to upload the
 jars (so far not source or javadoc).

 Let me know if it needs any more tweaking.

 Have you seen the snapshots I uploaded?
 Do the poms work OK?

 If not, what needs to be fixed?

 Regards

 Mark

 -Original Message-
 From: Mark Collin [mailto:m...@ardescosolutions.com]
 Sent: 18 January 2012 14:10
 To: dev@jmeter.apache.org
 Subject: RE: Publishing to Maven Central

 I was trying to find a way that would use a unified dependency list
 for both the ant build and the maven deploy.

 The path I have been going down is creating a dependency POM for doc,
 core and api and making them required dependencies of
 ApacheJMeter_parent.  I have then modified build.xml to use these
 dependencies instead of build.properties, but I'm running into issues
 with the existing classpath declaration in the build.xml because it
 doesn't just use all of the files in core, doc, or api.

 I'll upload what I currently have


 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 18 January 2012 12:41
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central

 On 18 January 2012 12:30, Mark Collin m...@ardescosolutions.com wrote:
 It looks like you have specified all of the dependencies in the
 ApacheJMeter_parent pom.

 I thought you wanted a unified set of dependencies that are only
 declared in one place.

 Ideally, yes, but that looks to be hard to do.
 This approach should be enough to publish the jars and it's not to
 hard to maintain.
 If it can be improved later, so much the better.

 The code I have right now will deploy to a repo using ant to call the
 mvn deploy command via an exec command.  It's working on Linux and
 Windows and just requires you to have maven installed upon your system.

 Does it use standard Ant?
 Can you attach the file to the Bugzilla issue so I can try it?

 I can add in the dependency list to the parent.pom and it will all
 work
 right now.

 Huh?
 What's wrong with the existing dependency list in ApacheJMeter_parent
 pom?

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 18 January 2012 10:56
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central

 On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com
 wrote:
 I'm in the progress of writing my second attempt at providing a
 working maven solution which you can see here:

 It looks to me like an Ant build script using Maven deploy, i.e.
 Maven is not used for building.

 https://github.com/Ardesco/jmeter/tree/trunk/maven

 The sticking point I have at the moment is plugging in the
 dependencies, I have been looking at tweaking the existing ant
 script to use maven-ant-tasks, this is how far I have got (It doesn't
 work yet):

 https://github.com/Ardesco/jmeter/blob/trunk/build.xml

 Downloading the dependencies is trivial, however finding a nice way
 to specify individual jars for the classpaths and the release
 mechanism is not quite so tidy, the most sane way would seem to be a
 series of POM files to set the dependencies for each requirement but
 I'm not sure if that is changing the existing build process too much.

 Ant does not care about the dependencies being distributed
 accurately, so long as all the dependencies are present.

 AFAIK Maven need not either; if the parent depends on all the 3rd
 party libs, then every JMeter jar can depend on the parent.

 Intra-module dependencies in JMeter are quite simple and don't
 (generally must not) change.

 Today I was planning on having a look at building some dependency
 POM's for the maven deploy on the fly from the build.properties as
 maybe a saner way to do things which will won't touch the existing
 build.xml at all, although I'm not that happy with this solution
 either

 --
 This message contains confidential information and is intended only for
 the individual named. If you are not the named addressee you should not
 disseminate, distribute or copy this e-mail. Please notify the sender
 immediately by e-mail if you have received this e-mail by mistake and
 delete this e-mail from your system. If you are not the intended recipient
 you are notified that disclosing, copying, distributing or taking any
 action in reliance

RE: Publishing to Maven Central

[Mark Collin]

Oh this has highlighted another difference between the implementation I
supplied and your one, I have a POM named ApacheJMeter_reports and you have
one named ApacheJMeter_report.  If you do want to use the one I supplied
you'll need to take the s off the name to make it match your current POM.

-Original Message-
From: Mark Collin [mailto:m...@ardescosolutions.com] 
Sent: 19 January 2012 09:09
To: dev@jmeter.apache.org
Subject: RE: Publishing to Maven Central

OK I have tried using the 2.6-SNAPSHOT at
https://repository.apache.org/content/repositories/snapshots/ and I get the
following dependency issues:

[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1) org.bouncycastle:bcmail-jdk15:jar:$(bcmail.version}

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.bouncycastle
-DartifactId=bcmail-jdk15 -Dversion=$(bcmail.version} -Dpackaging=jar
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file
there:
  mvn deploy:deploy-file -DgroupId=org.bouncycastle
-DartifactId=bcmail-jdk15 -Dversion=$(bcmail.version} -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
1) org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT
2) org.apache.jmeter:ApacheJMeter_core:jar:2.6-SNAPSHOT
3) org.bouncycastle:bcmail-jdk15:jar:$(bcmail.version}

2) maven-plugins:maven-cobertura-plugin:plugin:1.3

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=maven-plugins
-DartifactId=maven-cobertura-plugin -Dversion=1.3 -Dpackaging=plugin
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file
there:
  mvn deploy:deploy-file -DgroupId=maven-plugins
-DartifactId=maven-cobertura-plugin -Dversion=1.3 -Dpackaging=plugin
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
1) org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT
2) org.apache.jmeter:ApacheJMeter_core:jar:2.6-SNAPSHOT
3) org.jdom:jdom:jar:1.1.2
4) jaxen:jaxen:jar:1.1.3
5) maven-plugins:maven-cobertura-plugin:plugin:1.3

3) maven-plugins:maven-findbugs-plugin:plugin:1.3.1

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=maven-plugins
-DartifactId=maven-findbugs-plugin -Dversion=1.3.1 -Dpackaging=plugin
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file
there:
  mvn deploy:deploy-file -DgroupId=maven-plugins
-DartifactId=maven-findbugs-plugin -Dversion=1.3.1 -Dpackaging=plugin
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
1) org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT
2) org.apache.jmeter:ApacheJMeter_core:jar:2.6-SNAPSHOT
3) org.jdom:jdom:jar:1.1.2
4) jaxen:jaxen:jar:1.1.3
5) maven-plugins:maven-findbugs-plugin:plugin:1.3.1

4) org.apache.jmeter:ApacheJMeter_mail:jar:2.6-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.apache.jmeter
-DartifactId=ApacheJMeter_mail -Dversion=2.6-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file
there:
  mvn deploy:deploy-file -DgroupId=org.apache.jmeter
-DartifactId=ApacheJMeter_mail -Dversion=2.6-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
1) org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT
2) org.apache.jmeter:ApacheJMeter_mail:jar:2.6-SNAPSHOT

--
4 required artifacts are missing.

for artifact:
  org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  Java maven repo
(https://repository.apache.org/content/repositories/snapshots/),
  Maven JMeter Repo
(http://ardesco.github.com/jmeter-maven-plugin/repository)



[INFO]


Regards

Mark

 Sebb,

 There is a transitive dependency issue with JDOM pulling in jaxen 
 which by default tries to pull in some plugins that are not available:

 http://blog.cedarsoft.com/2011/12/fixing-maven-artifact-jaxen/
 http://jira.codehaus.org/browse/JAXEN-217

 This is fixed in the package I supplied yesterday by adding an 
 exclusion for jaxen.

 I have also added in a repo that has jchart 0.75 available, and one 
 for beanshell 2.0b5 (although checking just now I have

RE: Publishing to Maven Central

[Mark Collin]

Just tried the latest snapshot and everything looks good now. :)

Is the plan to push this up to the maven central repo when 2.6 final is
released?

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 19 January 2012 10:59
To: dev@jmeter.apache.org
Subject: Re: Publishing to Maven Central

On 19 January 2012 09:13, Mark Collin m...@ardescosolutions.com wrote:
 Oh this has highlighted another difference between the implementation 
 I supplied and your one, I have a POM named ApacheJMeter_reports and 
 you have one named ApacheJMeter_report.  If you do want to use the one 
 I supplied you'll need to take the s off the name to make it match your
current POM.

I changed that so the pom matches the jar name, makes the Ant file simpler.

 -Original Message-
 From: Mark Collin [mailto:m...@ardescosolutions.com]
 Sent: 19 January 2012 09:09
 To: dev@jmeter.apache.org
 Subject: RE: Publishing to Maven Central

 OK I have tried using the 2.6-SNAPSHOT at 
 https://repository.apache.org/content/repositories/snapshots/ and I 
 get the following dependency issues:

 [INFO]
 --
 --
 [ERROR] BUILD ERROR
 [INFO]
 --
 --
 [INFO] Failed to resolve artifact.

 Missing:
 --
 1) org.bouncycastle:bcmail-jdk15:jar:$(bcmail.version}

  Try downloading the file manually from the project website.

  Then, install it using the command:
      mvn install:install-file -DgroupId=org.bouncycastle
 -DartifactId=bcmail-jdk15 -Dversion=$(bcmail.version} -Dpackaging=jar 
 -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the 
 file
 there:
      mvn deploy:deploy-file -DgroupId=org.bouncycastle
 -DartifactId=bcmail-jdk15 -Dversion=$(bcmail.version} -Dpackaging=jar 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
        1) org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT
        2) org.apache.jmeter:ApacheJMeter_core:jar:2.6-SNAPSHOT
        3) org.bouncycastle:bcmail-jdk15:jar:$(bcmail.version}

 2) maven-plugins:maven-cobertura-plugin:plugin:1.3

  Try downloading the file manually from the project website.

  Then, install it using the command:
      mvn install:install-file -DgroupId=maven-plugins 
 -DartifactId=maven-cobertura-plugin -Dversion=1.3 -Dpackaging=plugin 
 -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the 
 file
 there:
      mvn deploy:deploy-file -DgroupId=maven-plugins 
 -DartifactId=maven-cobertura-plugin -Dversion=1.3 -Dpackaging=plugin 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
        1) org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT
        2) org.apache.jmeter:ApacheJMeter_core:jar:2.6-SNAPSHOT
        3) org.jdom:jdom:jar:1.1.2
        4) jaxen:jaxen:jar:1.1.3
        5) maven-plugins:maven-cobertura-plugin:plugin:1.3

 3) maven-plugins:maven-findbugs-plugin:plugin:1.3.1

  Try downloading the file manually from the project website.

  Then, install it using the command:
      mvn install:install-file -DgroupId=maven-plugins 
 -DartifactId=maven-findbugs-plugin -Dversion=1.3.1 -Dpackaging=plugin 
 -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the 
 file
 there:
      mvn deploy:deploy-file -DgroupId=maven-plugins 
 -DartifactId=maven-findbugs-plugin -Dversion=1.3.1 -Dpackaging=plugin 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
        1) org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT
        2) org.apache.jmeter:ApacheJMeter_core:jar:2.6-SNAPSHOT
        3) org.jdom:jdom:jar:1.1.2
        4) jaxen:jaxen:jar:1.1.3
        5) maven-plugins:maven-findbugs-plugin:plugin:1.3.1

 4) org.apache.jmeter:ApacheJMeter_mail:jar:2.6-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
      mvn install:install-file -DgroupId=org.apache.jmeter 
 -DartifactId=ApacheJMeter_mail -Dversion=2.6-SNAPSHOT -Dpackaging=jar 
 -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the 
 file
 there:
      mvn deploy:deploy-file -DgroupId=org.apache.jmeter 
 -DartifactId=ApacheJMeter_mail -Dversion=2.6-SNAPSHOT -Dpackaging=jar 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
        1) org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT
        2) org.apache.jmeter:ApacheJMeter_mail:jar:2.6-SNAPSHOT

 --
 4 required artifacts are missing.

 for artifact:
  org.apache.jmeter:maven-jmeter-plugin:maven-plugin:SNAPSHOT

 from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  Java maven repo
 (https://repository.apache.org/content/repositories/snapshots/),
  Maven JMeter Repo
 (http://ardesco.github.com/jmeter-maven-plugin/repository)



 [INFO

RE: Publishing to Maven Central

[Mark Collin]

It looks like you have specified all of the dependencies in the
ApacheJMeter_parent pom.

I thought you wanted a unified set of dependencies that are only declared in
one place.

The code I have right now will deploy to a repo using ant to call the mvn
deploy command via an exec command.  It's working on Linux and Windows and
just requires you to have maven installed upon your system.  I can add in
the dependency list to the parent.pom and it will all work right now.

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 18 January 2012 10:56
To: dev@jmeter.apache.org
Subject: Re: Publishing to Maven Central

On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote:
 I'm in the progress of writing my second attempt at providing a 
 working maven solution which you can see here:

It looks to me like an Ant build script using Maven deploy, i.e. Maven is
not used for building.

 https://github.com/Ardesco/jmeter/tree/trunk/maven

 The sticking point I have at the moment is plugging in the 
 dependencies, I have been looking at tweaking the existing ant script 
 to use maven-ant-tasks, this is how far I have got (It doesn't work yet):

 https://github.com/Ardesco/jmeter/blob/trunk/build.xml

 Downloading the dependencies is trivial, however finding a nice way to 
 specify individual jars for the classpaths and the release mechanism 
 is not quite so tidy, the most sane way would seem to be a series of 
 POM files to set the dependencies for each requirement but I'm not 
 sure if that is changing the existing build process too much.

Ant does not care about the dependencies being distributed accurately, so
long as all the dependencies are present.

AFAIK Maven need not either; if the parent depends on all the 3rd party
libs, then every JMeter jar can depend on the parent.

Intra-module dependencies in JMeter are quite simple and don't (generally
must not) change.

 Today I was planning on having a look at building some dependency 
 POM's for the maven deploy on the fly from the build.properties as 
 maybe a saner way to do things which will won't touch the existing 
 build.xml at all, although I'm not that happy with this solution either.

Have you seen the POMs I comitted ro res/maven yesterday?

I was planning on using Maven deploy to upload them to a SNAPSHOT repo.

Someone can then see if the result is usable.


 -Original Message-
 From: Ian Brandt [mailto:i...@ianbrandt.com]
 Sent: 18 January 2012 05:04
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central


 On Jan 17, 2012, at 4:10 PM, sebb wrote:

 IMO Maven works well for some projects, particularly single component
 (module) builds.
 Multi-module Maven does not work as well; in particular the test 
 phase requires the project to be (re)installed first.

 Understood.  I like Steve Ebersole's writeup of such issues he 
 encountered with Hibernate [1].  On the other hand I maintain a 20 
 module Maven build at my company, having converted it from Ant a few 
 years back, and have no regrets and minimal issues.

 JMeter dependencies don't tend to change very frequently, so the 
 question is: is the effort required to introduce Ivy/MAT worth it?

 Good question, I can only offer anecdote.

 Before moving my company's build to Maven I first tried the Maven Ant 
 Tasks and then Ivy.  The situation was that we had a large (50+) and 
 frequently changing list of direct and transient dependencies.  With 
 no way to comprehend all the relationships it was proving a 
 maintenance nightmare to not use a dependency manager.  MAT proved 
 lacking in needed functionality at the time, so that attempt was short 
 lived.  With Ivy I can't remember the specifics, but I remember 
 hitting enough issues and struggling with the documentation such that 
 one day I just gave up and switched the entire build to Maven.  I'd 
 have to say that for either MAT or Ivy to be worth it they'd need to 
 have matured since then.  It's encouraging to see there is now 
 Sonatype and Apache documentation on publishing to Maven repositories 
 with
 them: [2], [3].

 If JMeter has a small and unchanging set of dependencies then the 
 situation is different.  I'd only add that with any dependency 
 management system the correctness of the declared relationships is 
 everything, and with Maven you generally get one chance to get it 
 right when publishing a given version to Central.  Tomcat has fewer 
 external dependencies than JMeter I believe, and yet in my experience 
 the Tomcat POMs aren't always right.  I'm proposing that MAT or Ivy 
 might lead to higher quality POMs being published by JMeter because 
 the exact same dependency information would be used to compile and test
beforehand.

 I assume that the main build and release procedures would be unaffected?
 Is that correct?

 I've looked oven the Ant build, the README, and the Release Creation 
 document on the Wiki [4].  Nothing jumps out as likely to be affected 
 by MAT or Ivy

RE: Publishing to Maven Central

[Mark Collin]

I was trying to find a way that would use a unified dependency list for both
the ant build and the maven deploy.  

The path I have been going down is creating a dependency POM for doc, core
and api and making them required dependencies of ApacheJMeter_parent.  I
have then modified build.xml to use these dependencies instead of
build.properties, but I'm running into issues with the existing classpath
declaration in the build.xml because it doesn't just use all of the files in
core, doc, or api.

I'll upload what I currently have


-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 18 January 2012 12:41
To: dev@jmeter.apache.org
Subject: Re: Publishing to Maven Central

On 18 January 2012 12:30, Mark Collin m...@ardescosolutions.com wrote:
 It looks like you have specified all of the dependencies in the 
 ApacheJMeter_parent pom.

 I thought you wanted a unified set of dependencies that are only 
 declared in one place.

Ideally, yes, but that looks to be hard to do.
This approach should be enough to publish the jars and it's not to hard to
maintain.
If it can be improved later, so much the better.

 The code I have right now will deploy to a repo using ant to call the 
 mvn deploy command via an exec command.  It's working on Linux and 
 Windows and just requires you to have maven installed upon your system.

Does it use standard Ant?
Can you attach the file to the Bugzilla issue so I can try it?

 I can add in the dependency list to the parent.pom and it will all work
right now.

Huh?
What's wrong with the existing dependency list in ApacheJMeter_parent pom?

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 18 January 2012 10:56
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central

 On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote:
 I'm in the progress of writing my second attempt at providing a 
 working maven solution which you can see here:

 It looks to me like an Ant build script using Maven deploy, i.e. Maven 
 is not used for building.

 https://github.com/Ardesco/jmeter/tree/trunk/maven

 The sticking point I have at the moment is plugging in the 
 dependencies, I have been looking at tweaking the existing ant script 
 to use maven-ant-tasks, this is how far I have got (It doesn't work yet):

 https://github.com/Ardesco/jmeter/blob/trunk/build.xml

 Downloading the dependencies is trivial, however finding a nice way 
 to specify individual jars for the classpaths and the release 
 mechanism is not quite so tidy, the most sane way would seem to be a 
 series of POM files to set the dependencies for each requirement but 
 I'm not sure if that is changing the existing build process too much.

 Ant does not care about the dependencies being distributed accurately, 
 so long as all the dependencies are present.

 AFAIK Maven need not either; if the parent depends on all the 3rd 
 party libs, then every JMeter jar can depend on the parent.

 Intra-module dependencies in JMeter are quite simple and don't 
 (generally must not) change.

 Today I was planning on having a look at building some dependency 
 POM's for the maven deploy on the fly from the build.properties as 
 maybe a saner way to do things which will won't touch the existing 
 build.xml at all, although I'm not that happy with this solution either.

 Have you seen the POMs I comitted ro res/maven yesterday?

 I was planning on using Maven deploy to upload them to a SNAPSHOT repo.

 Someone can then see if the result is usable.


 -Original Message-
 From: Ian Brandt [mailto:i...@ianbrandt.com]
 Sent: 18 January 2012 05:04
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central


 On Jan 17, 2012, at 4:10 PM, sebb wrote:

 IMO Maven works well for some projects, particularly single 
 component
 (module) builds.
 Multi-module Maven does not work as well; in particular the test 
 phase requires the project to be (re)installed first.

 Understood.  I like Steve Ebersole's writeup of such issues he 
 encountered with Hibernate [1].  On the other hand I maintain a 20 
 module Maven build at my company, having converted it from Ant a few 
 years back, and have no regrets and minimal issues.

 JMeter dependencies don't tend to change very frequently, so the 
 question is: is the effort required to introduce Ivy/MAT worth it?

 Good question, I can only offer anecdote.

 Before moving my company's build to Maven I first tried the Maven Ant 
 Tasks and then Ivy.  The situation was that we had a large (50+) and 
 frequently changing list of direct and transient dependencies.  With 
 no way to comprehend all the relationships it was proving a 
 maintenance nightmare to not use a dependency manager.  MAT proved 
 lacking in needed functionality at the time, so that attempt was 
 short lived.  With Ivy I can't remember the specifics, but I remember 
 hitting enough issues and struggling with the documentation such that 
 one day I just gave up

RE: Publishing to Maven Central

[Mark Collin]

Uploaded a final version just now.

I had to fix some transitive dependency problems that were not apparent
until you tried to use the artifacts and I had one POM that was not
correctly referencing ApacheJMeter_parent. 

The final version will also automatically download ant-contrib if you don't
have it to make the whole process easier.

Let me know if it needs any more tweaking.

Regards

Mark

-Original Message-
From: Mark Collin [mailto:m...@ardescosolutions.com] 
Sent: 18 January 2012 14:10
To: dev@jmeter.apache.org
Subject: RE: Publishing to Maven Central

I was trying to find a way that would use a unified dependency list for both
the ant build and the maven deploy.  

The path I have been going down is creating a dependency POM for doc, core
and api and making them required dependencies of ApacheJMeter_parent.  I
have then modified build.xml to use these dependencies instead of
build.properties, but I'm running into issues with the existing classpath
declaration in the build.xml because it doesn't just use all of the files in
core, doc, or api.

I'll upload what I currently have


-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 18 January 2012 12:41
To: dev@jmeter.apache.org
Subject: Re: Publishing to Maven Central

On 18 January 2012 12:30, Mark Collin m...@ardescosolutions.com wrote:
 It looks like you have specified all of the dependencies in the 
 ApacheJMeter_parent pom.

 I thought you wanted a unified set of dependencies that are only 
 declared in one place.

Ideally, yes, but that looks to be hard to do.
This approach should be enough to publish the jars and it's not to hard to
maintain.
If it can be improved later, so much the better.

 The code I have right now will deploy to a repo using ant to call the 
 mvn deploy command via an exec command.  It's working on Linux and 
 Windows and just requires you to have maven installed upon your system.

Does it use standard Ant?
Can you attach the file to the Bugzilla issue so I can try it?

 I can add in the dependency list to the parent.pom and it will all 
 work
right now.

Huh?
What's wrong with the existing dependency list in ApacheJMeter_parent pom?

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 18 January 2012 10:56
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central

 On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote:
 I'm in the progress of writing my second attempt at providing a 
 working maven solution which you can see here:

 It looks to me like an Ant build script using Maven deploy, i.e. Maven 
 is not used for building.

 https://github.com/Ardesco/jmeter/tree/trunk/maven

 The sticking point I have at the moment is plugging in the 
 dependencies, I have been looking at tweaking the existing ant script 
 to use maven-ant-tasks, this is how far I have got (It doesn't work yet):

 https://github.com/Ardesco/jmeter/blob/trunk/build.xml

 Downloading the dependencies is trivial, however finding a nice way 
 to specify individual jars for the classpaths and the release 
 mechanism is not quite so tidy, the most sane way would seem to be a 
 series of POM files to set the dependencies for each requirement but 
 I'm not sure if that is changing the existing build process too much.

 Ant does not care about the dependencies being distributed accurately, 
 so long as all the dependencies are present.

 AFAIK Maven need not either; if the parent depends on all the 3rd 
 party libs, then every JMeter jar can depend on the parent.

 Intra-module dependencies in JMeter are quite simple and don't 
 (generally must not) change.

 Today I was planning on having a look at building some dependency 
 POM's for the maven deploy on the fly from the build.properties as 
 maybe a saner way to do things which will won't touch the existing 
 build.xml at all, although I'm not that happy with this solution either.

 Have you seen the POMs I comitted ro res/maven yesterday?

 I was planning on using Maven deploy to upload them to a SNAPSHOT repo.

 Someone can then see if the result is usable.


 -Original Message-
 From: Ian Brandt [mailto:i...@ianbrandt.com]
 Sent: 18 January 2012 05:04
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central


 On Jan 17, 2012, at 4:10 PM, sebb wrote:

 IMO Maven works well for some projects, particularly single 
 component
 (module) builds.
 Multi-module Maven does not work as well; in particular the test 
 phase requires the project to be (re)installed first.

 Understood.  I like Steve Ebersole's writeup of such issues he 
 encountered with Hibernate [1].  On the other hand I maintain a 20 
 module Maven build at my company, having converted it from Ant a few 
 years back, and have no regrets and minimal issues.

 JMeter dependencies don't tend to change very frequently, so the 
 question is: is the effort required to introduce Ivy/MAT worth it?

 Good question, I can only offer anecdote.

 Before moving

RE: Publishing to Maven Central

[Mark Collin]

Sebb,

There is a transitive dependency issue with JDOM pulling in jaxen which by
default tries to pull in some plugins that are not available:

http://blog.cedarsoft.com/2011/12/fixing-maven-artifact-jaxen/
http://jira.codehaus.org/browse/JAXEN-217

This is fixed in the package I supplied yesterday by adding an exclusion for
jaxen.

I have also added in a repo that has jchart 0.75 available, and one for
beanshell 2.0b5 (although checking just now I have missed the dependency
block for beanshell in the parent POM so it isn't actually pulling beanshell
down).

I'll look at it in a bit more anger in a couple of hours to provide some
more useful feedback.

Ant-contrib is used in the patch I have supplied to loop through a couple of
lists and add in an if/else block that will allow you to choose if you want
to add sources and javadoc jars when deploying, if you don't want to do
these things it isn't needed.

Regards

Mark

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 18 January 2012 23:39
To: dev@jmeter.apache.org
Subject: Re: Publishing to Maven Central

On 18 January 2012 22:45, Mark Collin m...@ardescosolutions.com wrote:
 Uploaded a final version just now.

 I had to fix some transitive dependency problems that were not 
 apparent until you tried to use the artifacts and I had one POM that 
 was not correctly referencing ApacheJMeter_parent.

 The final version will also automatically download ant-contrib if you 
 don't have it to make the whole process easier.

I don't think we need the ant-contrib; so long as Maven is locally installed
it's possible to access it using Java.

I recently committed an Ant script that uses this technique to upload the
jars (so far not source or javadoc).

 Let me know if it needs any more tweaking.

Have you seen the snapshots I uploaded?
Do the poms work OK?

If not, what needs to be fixed?

 Regards

 Mark

 -Original Message-
 From: Mark Collin [mailto:m...@ardescosolutions.com]
 Sent: 18 January 2012 14:10
 To: dev@jmeter.apache.org
 Subject: RE: Publishing to Maven Central

 I was trying to find a way that would use a unified dependency list 
 for both the ant build and the maven deploy.

 The path I have been going down is creating a dependency POM for doc, 
 core and api and making them required dependencies of 
 ApacheJMeter_parent.  I have then modified build.xml to use these 
 dependencies instead of build.properties, but I'm running into issues 
 with the existing classpath declaration in the build.xml because it 
 doesn't just use all of the files in core, doc, or api.

 I'll upload what I currently have


 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 18 January 2012 12:41
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central

 On 18 January 2012 12:30, Mark Collin m...@ardescosolutions.com wrote:
 It looks like you have specified all of the dependencies in the 
 ApacheJMeter_parent pom.

 I thought you wanted a unified set of dependencies that are only 
 declared in one place.

 Ideally, yes, but that looks to be hard to do.
 This approach should be enough to publish the jars and it's not to 
 hard to maintain.
 If it can be improved later, so much the better.

 The code I have right now will deploy to a repo using ant to call the 
 mvn deploy command via an exec command.  It's working on Linux and 
 Windows and just requires you to have maven installed upon your system.

 Does it use standard Ant?
 Can you attach the file to the Bugzilla issue so I can try it?

 I can add in the dependency list to the parent.pom and it will all 
 work
 right now.

 Huh?
 What's wrong with the existing dependency list in ApacheJMeter_parent pom?

 -Original Message-
 From: sebb [mailto:seb...@gmail.com]
 Sent: 18 January 2012 10:56
 To: dev@jmeter.apache.org
 Subject: Re: Publishing to Maven Central

 On 18 January 2012 06:35, Mark Collin m...@ardescosolutions.com wrote:
 I'm in the progress of writing my second attempt at providing a 
 working maven solution which you can see here:

 It looks to me like an Ant build script using Maven deploy, i.e. 
 Maven is not used for building.

 https://github.com/Ardesco/jmeter/tree/trunk/maven

 The sticking point I have at the moment is plugging in the 
 dependencies, I have been looking at tweaking the existing ant 
 script to use maven-ant-tasks, this is how far I have got (It doesn't
work yet):

 https://github.com/Ardesco/jmeter/blob/trunk/build.xml

 Downloading the dependencies is trivial, however finding a nice way 
 to specify individual jars for the classpaths and the release 
 mechanism is not quite so tidy, the most sane way would seem to be a 
 series of POM files to set the dependencies for each requirement but 
 I'm not sure if that is changing the existing build process too much.

 Ant does not care about the dependencies being distributed 
 accurately, so long as all the dependencies are present.

 AFAIK Maven need not either

RE: BUG-49753 Fix

[Mark Collin]

I've uploaded an archive as requested, I've updated it just now to pull in
three modules that were originally missed.

-Original Message-
From: Mark Collin [mailto:m...@ardescosolutions.com] 
Sent: 10 January 2012 20:59
To: dev@jmeter.apache.org
Subject: RE: BUG-49753 Fix

Added a patch file to the bug.

-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: 10 January 2012 13:51
To: dev@jmeter.apache.org
Subject: Re: BUG-49753 Fix

On 10 January 2012 11:19, Mark Collin m...@ardescosolutions.com wrote:
 I've implemented the enhancement BUG-49753 which is checked into 
 github and I have sent you a pull request here:



 https://github.com/apache/jmeter/pull/2



 Is there any chance of getting this added in?

Please can you attach the files to the Bugzilla issue?

Sorry, but we need that for tracking provenance.

 It would be nice to get some
 mavenised artefacts for JMeter building and eventually uploaded to the 
 main maven repo.


 --
 This message contains confidential information and is intended only 
 for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify
postmas...@ardescosolutions.com
--
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify
postmas...@ardescosolutions.com

--
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify 
postmas...@ardescosolutions.com

CompoundVariable classfinder.functions

[Mark Collin]

Looking through the code whilst debugging a problem with my maven
implementation today I found out that CompoundVariable in core - engine -
util searches for functions in jars that are in the search_path and the
lib/ext folder but it completely ignores anything in the classpath.  

 

However when JMeter loads it checks the java.class.path to report which jars
are available to it which can be slightly confusing when you get a

 

Jmeter.engine.util.CompoundVariable: Did not find any functions

 

I'm thinking of adding a patch to check the classpath rather than the
lib/ext dir as looking at the logs everything in the lib/ext dir seems to be
added to the classpath anyway (I haven't worked through the code to see if
this assumption is correct yet, but everything in lib/ext is logged as being
in the classpath when in DEBUG mode so I assume that's correct).  

 

Is there a reason you aren't checking the classpath?

 

Would I be wasting my time changing this?


--
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify 
postmas...@ardescosolutions.com

RE: CompoundVariable classfinder.functions

[Mark Collin]

In that case it would seem like the path of least resistance is to copy all
JMeter component jars into the lib/ext folder. 

The other option would be to enforce a naming structure for JMeter
components (e.g. they must always start with ApacheJMeter_) then you could
scan the classpath and only pick up JMeter components to search through for
functions.

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 11 January 2012 13:35
To: dev@jmeter.apache.org
Subject: Re: CompoundVariable classfinder.functions

On 11 January 2012 13:18, Mark Collin m...@ardescosolutions.com wrote:
 Looking through the code whilst debugging a problem with my maven 
 implementation today I found out that CompoundVariable in core - 
 engine - util searches for functions in jars that are in the 
 search_path and the lib/ext folder but it completely ignores anything in
the classpath.



 However when JMeter loads it checks the java.class.path to report 
 which jars are available to it which can be slightly confusing when 
 you get a



 Jmeter.engine.util.CompoundVariable: Did not find any functions



 I'm thinking of adding a patch to check the classpath rather than the 
 lib/ext dir as looking at the logs everything in the lib/ext dir seems 
 to be added to the classpath anyway (I haven't worked through the code 
 to see if this assumption is correct yet, but everything in lib/ext is 
 logged as being in the classpath when in DEBUG mode so I assume that's
correct).



 Is there a reason you aren't checking the classpath?



 Would I be wasting my time changing this?

Possibly.

The way that JMeter searches for classes is quite complicated, as you have
found.
It's important that it restricts the search when looking for JMeter add-ons,
otherwise it can end up loading lots of unwanted classes.


 --
 This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

--
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify 
postmas...@ardescosolutions.com

RE: BUG-49753 Fix

[Mark Collin]

Added a patch file to the bug.

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: 10 January 2012 13:51
To: dev@jmeter.apache.org
Subject: Re: BUG-49753 Fix

On 10 January 2012 11:19, Mark Collin m...@ardescosolutions.com wrote:
 I've implemented the enhancement BUG-49753 which is checked into 
 github and I have sent you a pull request here:



 https://github.com/apache/jmeter/pull/2



 Is there any chance of getting this added in?

Please can you attach the files to the Bugzilla issue?

Sorry, but we need that for tracking provenance.

 It would be nice to get some
 mavenised artefacts for JMeter building and eventually uploaded to the 
 main maven repo.


 --
 This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.

 If you have received this email in error please notify 
 postmas...@ardescosolutions.com

--
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

If you have received this email in error please notify 
postmas...@ardescosolutions.com