On 08/07/2012 06:11 PM, sebb wrote: > On 7 August 2012 15:39, Dimitris Balaouras <[email protected]> wrote: >> On 08/07/2012 05:15 PM, sebb wrote: >>> On 7 August 2012 15:12, Shmuel Krakower <[email protected]> wrote: >>>> Sebb, I guess you missed the point of Dimitris - to try and run a script >>>> from jmeter 2.6 on jmeter2.5 executable. >>> Why would one want to do that? >> Sebb, I wouldn't ever want to do this. The use case goes like this: >> users upload jmx scripts into a web app and a proxy application >> delegates them to the correct jmeter executable for regular executions. >> I tend to agree that using the latest version is always safe, but >> sticking with one version provides some safety that all executions would >> occur under the exact same context (wrt software at least). That said, >> knowing the version of jM that was used to create a script would be handy. >> Of course the users can explicitly define this, but automation is always >> welcomed. >> >>>> Dimitris - as sebb wrote currently only jmx version is reflected in the jmx >>>> file, so you cannot directly know which version of jmeter was used to >>>> create this script. >>>> >>>> I do find it useful too to have the jmeter version saved into the jmx file. >>> Again, why? >> See above for a -hopefully- justified reason. Other than that, I'm >> wondering if it would cause any harm. > JMeter should just ignore the attribute when reading the file, but it > might cause some issues for unit tests that check JMX files can be > read and saved - at present the file size is checked, and that would > change if the version strings were different lengths. Might have to > make saving the attribute optional, at least for testing. > > Could potentially also affect 3rd party tools.
I see. >> Surely, if it's too much work or breaks conventions, I wouldn't put any >> effort on it. > OK, then raise a Bugzilla enhancement request. okay..I'll try that. > It probably would not be too difficult to save the current JMeter > version as a new attribute when writing a JMX file. > Of course this will be overwritten if the file is ever updated in a > different version of JMeter. yes...makes perfect sense. Thanks, Dimi > >> - Dimi >> >> >>>> Maybe you should open a bugzilla on this... >>>> >>>> On Tue, Aug 7, 2012 at 11:44 AM, sebb <[email protected]> wrote: >>>> >>>>> On 7 August 2012 09:20, Dimitris Balaouras <[email protected]> wrote: >>>>>> Hi there, >>>>>> >>>>>> When opening a jmx file that was created with a newer version of jmeter >>>>>> (e.g. 2.6) from an older version of jmeter (e.g. 2.3.4), an "error >>>>>> in test plan" is thrown; not a detailed error message but fair enough. >>>>>> >>>>>> I am wondering though, why is the version of jmeter that was used to >>>>> create the jmx missing from the file itself? Wouldn't be handy to have the >>>>> JMeter version in an attribute inside the jmeterTestPlan tag? >>>>>> example: <jmeterTestPlan version="1.2" properties="2.2" >>>>> jmeter:version="2.5.1"> >>>>> >>>>> The JMeter version does not directly affect the jmx version. >>>>> The intention was to update the "version" field whenever changes were >>>>> made, but some changes were unfortunately not reflected in the version >>>>> attribute. >>>>> >>>>>> Future versions of JMeter could use this attribute and external tools >>>>> can parse jmx files without the need of heuristics. In my case, a proxy >>>>> would be able to delegate the execution of the jmx to the correct jMeter >>>>> executable. >>>>> JMeter should be able to run test plans from previous versions, unless >>>>> the test plan is very old. >>>>> >>>>> If you have some examples where this does not apply, please raise a >>>>> Bugzilla report. >>>>> >>>>>> Thanks, >>>>>> -Dimitris >>>>>> -- ???????? ?????????? ??. ???/??? & ???/??? ?/? - ?????????? *T* +306976990146 *F* +302410285612 *E* [email protected] Twitter <http://twitter.com/#%21/dbalaouras> | LinkedIn <http://www.linkedin.com/in/dbalaouras> | G+ <https://plus.google.com/100211800323347120261/>
