I would like to hear Your opinion on that one.

Currently we have the following goals:

jmetergui: A convenience tool to invoke the jmetergui with correct classpath 
including classes of the current project.
jmeter: (currently part of integrationtest phase): Optionally invoke jmeter. 
convert output to an internal format.
check : (currently part of the verify phase) validate that performancegoals 
have been met.
report : (part of the site phase) create the report as part of the site

After splitting the project, chronos would probably have these goals:

jmeteroutout:  Convert jmeteroutput to an internal format.
(grinderoutput): Convert grinderoutput to an internal format. Planned to be 
done later.
check : validate that performancegoals have been met. Independent of choice of 
testtool.
report : create the report as part of the site. Independent of choice of 
testtool.

In that setup, I am unsure of the correct binding to phases. It just feels 
right" to have the check be part of the verify phase.
But for the user, configuration would be easier, if he uses one plugin for 
testing, and antoher plugin for reporting.
Any input on this?


Actually it would be possible to let a separate jmeterplugin convert the 
testresults to an independent format, but I tend to think that would make the 2 
plugins too tightly coupled.
And would require the user the use both plugins, even if he prefers to invoke 
JMeter directly.
I would not be surprised, if introduction of Grinder support would require 
changes to the internal format, which would be much more difficult if the 
format is a "published interface".

/Kent

Den 08/08/2011 kl. 10.23 skrev Anders Hammar:

> So the jmeter plugin would then be a build plugin while the chronos plugin 
> would be a reporting plugin?
> 
> /Anders
> 
> On Mon, Aug 8, 2011 at 09:57, Kent Sølvsten <k...@lakeside.dk> wrote:
> Hi
> 
> Thanks for Your comments.
> 
> I think the best way forward is to create a separate jmeter-maven-plugin in 
> the sandbox.
> The separation betwen the two projects should be:
> 
> 1) the (new) jmeter-maven-plugin may be used to invoke performancetests with 
> jmeter. Input is .jmx files containing the configuration of the 
> performancetest, output is .jtl-files containing the testresults.
> 2a) the chronos plugin is able to parse output from a jmeter test (output 
> created by using the jmeter-maven-plugin or by direct invocation) and convert 
> it to an internal format (tis already exists today).
> 2b) Later (post 1.0) support will probably be added for other 
> performancetesting tools, grinder being an obvious candidate. This will also 
> convert the native grinder output to an internal chronos for mat.
> 3) Chronos will analyse the results of the tests, testing that performance 
> goals have been met, at create nice reports.
> 
> Will this be okay? Can I just go ahead and create a new project, or will it 
> require a separate vote?
> 
> By the way, a separate issue regarding the structuring of the code, has been 
> raised. I believe it will be easier to handle after the separation of the two 
> parts (some tests are focused on the perf-testing part, others on the 
> reporting part).
> 
> /Kent
> 
> 
> Den 02/07/2011 kl. 23.03 skrev Anders Hammar:
> 
>>  
>> Why not extract the JMeter part and make a separate mojo-project of it? This 
>> might make a lot of people happy. The naming is less odd and there's an 
>> extra (JMeter) plugin with its own release cycle.
>> I wouldn't include some functionality of which you expect to be replaced in 
>> the (near) future.
>> 
>> I'm +1 of this. Especially as it is clearly something of the chronos plugin 
>> that you would deprecate later on. Deprecated stuff tends to stick for quite 
>> some time...
>> 
>> /Anders
>>  
>>  
>> -Robert
>>  
>> From: k...@lakeside.dk
>> Date: Thu, 30 Jun 2011 15:32:46 +0200
>> 
>> To: dev@mojo.codehaus.org
>> Subject: Re: [mojo-dev] Vote: Promote chronos from sandbox to proper
>> 
>> I see what You mean with the structuring. I am not sure that Your suggested 
>> structure is a no-brainer, since the integrationtests are a suite of small 
>> independent maven projects, and NOT normal java based tests.
>> But if other project do it this way, it should of course be aligned.
>> 
>> The naming may be odd at first. The focus of the plugin have never been 
>> performing the tests, but rather analyzing the output from the tests, 
>> tracking historic developments, checking that goals have been met...
>> 
>>  I believe in the concept of "do one thing and do it well". And the name 
>> jmeter-maven-plugin should IMHO be reserved for a plugin focused on invoking 
>> jmeter. When this project was started, there was no mature jmeter plugins at 
>> all, so "by coincidense"  support for that was added as well.
>> 
>> Actually the name jmeter-maven-plugin is already taken by  a project hosted 
>> at googlecode (later moved to github), which is focused on the execution of 
>> JMeter. It does not seem very mature to me yet, but it actually is possible 
>> to use the jmeter-maven-plugin to invoke the performancetests, and then use 
>> chronos to analyze the results.
>> 
>> As soon as i find a jmeter plugin which is mature enough, the intention is 
>> to deprecate the stuf about jmeter invocation inside chronos and recommend 
>> usage of other plugins to that task.
>> 
>> Any comments on that?
>> 
>> - Kent
>> 
>> 
>> 
>> Den 27/06/2011 kl. 22.41 skrev Robert Scholte:
>> 
>> IIRC there have been some issues with the licensing of this project. 
>> Suddenly it changed from MIT to some company copyright, but it looks like 
>> this has been reverted and slightly adjusted by mentioning some donation 
>> information. I think this is okay right now.
>>  
>> The project structure looks a bit strange to me. I would have expected:
>> chronos-maven-plugin
>>  \- src
>>      \- main
>>      \- test
>>      \- it (here the integration tests)
>> If there's no particular reason for this, consider restructuring it, so it 
>> would look more like most other mojo plugins.
>>  
>> I haven't looked at the code yet, but Kents comment sounds interesting. If 
>> JMeter is the only implementation, why not call it like that.
>> That would also make it easier to find for wandering users looking for some 
>> JMeter Maven-plugin.
>>  
>> -Robert
>> 
>> > Date: Mon, 27 Jun 2011 09:10:00 -0400
>> > From: jie...@gmail.com
>> > To: dev@mojo.codehaus.org
>> > Subject: Re: [mojo-dev] Vote: Promote chronos from sandbox to proper
>> > 
>> > Greetings,
>> > 
>> > On Mon, Jun 27, 2011 at 4:08 AM, Kent Sølvsten <k...@lakeside.dk> wrote:
>> > > I believe now is the time to promote the plugin from the sandbox. Since 
>> > > the code should be in a pretty stable state, I expect to head 
>> > > immediately for a beta release, and then hopefully a final 1.0 release 
>> > > within a month or 2.
>> > 
>> > I don't have a binding vote. I find the naming of this plugin to be
>> > kind of misleading though, since all of the goals seem to deal with
>> > JMeter. Wouldn't this plugin fair better if named jmeter-maven-plugin?
>> > Or something else which otherwise informs the uninformed, at a glance,
>> > what this plugin is likely about..
>> > 
>> > -Jesse
>> > 
>> > -- 
>> > There are 10 types of people in this world, those
>> > that can read binary and those that can not.
>> > 
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> > 
>> > http://xircles.codehaus.org/manage_email
>> > 
>> > 
>> 
>> 
> 
> 

Reply via email to