I noticed you've already started with the little more work. I would call the root-folder just 'chronos' instead of chronos-maven-plugin, because I expect there will be at least one shared jar for the different plugins.
I think chronos-jmeter-maven-plugin is the right name: name reflects the used implementation. There is still the possibility to implement a chronos-maven-plugin which can pick up the right provider based certain files/configuration (just a nice-to-have). The chronos-report-maven-plugin seems to be the right name too. And I agree with Mark: the idea behind this plugin is really nice -Robert ---------------------------------------- > From: k...@lakeside.dk > Date: Tue, 9 Aug 2011 15:53:10 +0200 > To: dev@mojo.codehaus.org > Subject: Re: [mojo-dev] Vote: Promote chronos from sandbox to proper > > It will be a little more work (I hate that!), but I think You are right. > > I would suggest these names and responsibilities then. > > chronos-jmeter: responsible for performancetesting with jmeter. Results will > be converted to a chronos-specific xml format > chronos-report : responsible for analyzing and reporting result. Features: > check that performancegoals have been made, generate report, save a historic > snapshot, generating historic reports based on different old testruns > > and then later (post 1.0): > chronos-grinder: responsible for performancetesting with grinder. Results > will be converted to a chronos-specific xml format > > The native dataformat for grinder seem to be pretty consistent with the > existing chronos format, so it should not be too difficult to add that later. > > Any thoughts on this? Do You agree onthe suggested naming? > > /Kent > > > > Den 09/08/2011 kl. 13.13 skrev Mark Struberg: > > > +1, sounds like the way to go. > > > > LieGrue, > > strub > > > > PS: and I like the overall idea behind this plugin! > > > > > > --- On Mon, 8/8/11, Robert Scholte <rfscho...@codehaus.org> wrote: > > > > From: Robert Scholte <rfscho...@codehaus.org> > > Subject: RE: [mojo-dev] Vote: Promote chronos from sandbox to proper > > To: dev@mojo.codehaus.org > > Date: Monday, August 8, 2011, 4:49 PM > > > > > > > > > > > > > > I think you should let both jmeter and grinder generate an chronos output > > file. > > This will keep the report-plugin much cleaner. > > This looks actually a bit like surefire and surefire-report. > > For junit and testng are so-called providers and there's only one report > > plugin for all. > > Maybe that's a better architecture. > > > > -Robert > > From: k...@lakeside.dk > > Date: Mon, 8 Aug 2011 11:18:00 +0200 > > To: dev@mojo.codehaus.org > > Subject: Re: [mojo-dev] Vote: Promote chronos from sandbox to proper > > > > > > > > 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 > >> > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
