> 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 > > > > > > >
