http://wiki.apache.org/jakarta-jmeter/JMeterFAQ#head-2bd2acc0ddc4dc65e9aad086b024ff6b81bd751b
http://jakarta.apache.org/jmeter/usermanual/functions.html
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#User_Defined_Variables
http://jakarta.apache.org/jmeter/usermanual/component_
It's only in the rel-2-0 branch. Gump won't be using this build file.
Though, the main build file does need this change.
-Mike
On Mon, 2004-04-05 at 07:17, BAZLEY, Sebastian wrote:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 04 April 2004 15:00
> To:
On Sun, 2004-04-04 at 20:08, [EMAIL PROTECTED] wrote:
> Seems fine - thanks very much for doing this.
>
> ==
>
> I'd like to suggest some changes to the contents of the archives for the next
> release.
>
> Binary archive:
> jmetertest.properties is only needed for testing, likewise the bin/test
>
> > Releases will be tagged with names like rel-2_0_0, rel-2_0_1, etc. I'll
> > take care of merging bug fixes from the branch into main development (so
> > please don't make bug fixes in both places).
>
> Sorry, I don't I understand.
>
> Should we commit all changes in the branch, or should
I'd like to make the 2.0 cvs branch now if people don't mind. I find it
really makes things easier to make release branches. I know there are
people who want to begin new development, and a branch makes that
possible while also allowing very frequent bug fix releases.
If no one has an objection,
sified it wrongly.]
> >
> > Yes, I think this is long due. Sebb should have the last word: I'm sure
> > he knows the product's status.
> >
> > --
> > Salut,
> >
> > Jordi
> >
> > mstover wrote:
> > > I've fin
I've finally got my cvs access back (yay!) and I could make a release
this weekend if you guys are ready. What you say?
-Mike
On Fri, 2004-03-26 at 14:34, Michal Kostrzewa wrote:
> > How about
> >
> > Documentation
> >
> > * User Manual (1.9.1)
> > * User Manual (nightly)
> > * Developer Docs
I'm not talking about making the context itself read-only, just the
getContext() method that retrieves the context according to the current
thread. Each context should be accessible only to a single thread via
this strategy and shouldn't need synchronization for read or write
operations.
I wouldn
How would that cause a problem? The Map that holds the thread contexts
is only being read, not written to. So, many threads can ask for their
context simultaneously, this should not be a problem. Unless you can
think of a scenario that is problematic?
-Mike
On Wed, 2004-03-17 at 09:53, Michal
Yes, this matches what I've seen from jakarta's pmc - they theoretically
want all committers on the pmc, and they're eager to have more thorough
oversight of the projects in jakarta.
Right now, JMeter seems to fly under the radar and not get much
attention, which seems to be something most of us
I'm subscribing to the board mailing list to see what's going on. In
the meantime, I suggest we figure out what our strategy will be for
removing the binaries and helping end users get them. There are some
various options, not necessarily exclusive:
1. Adopt Maven to help with grabbing dependenc
Actually, I just noticed this yesterday.
It's a bad bug that needs to be fixed. If you are hopping around your
previously recorded samplers while simultaneously recording new samplers
through the proxy, it can overwrite the sampler currently selected.
-Mike
On Wed, 2004-02-11 at 19:10, Mar
12 matches
Mail list logo
