JMeter has just been offered a Maven plugin for creating reports.
Rather than include the code in JMeter, I think it would be better
hosted at mojo.codehaus.org, along with the other Maven plugins.
That got me thinking - perhaps a similar idea could be set up for
JMeter plugins?
Or is that a silly idea?
Sebb
Any particular reason, why this can not be a part of the JMeter project?
Splitting a rather small community into two parts (apache + codehaus)
does not sound too good. Having that plugin inside the JMeter project
might lead to new hands helping out with JMeter itself.
Gaining gravity in the project is IMHO a good thing. You might want to
move TLP at some distant point in the future.
Best regards
Henning
On Sat, 2007-10-06 at 13:27 +0100, sebb wrote:
> JMeter has just been offered a Maven plugin for creating reports.
>
> Rather than include the code in JMeter, I think it would be better
> hosted at mojo.codehaus.org, along with the other Maven plugins.
>
> That got me thinking - perhaps a similar idea could be set up for
> JMeter plugins?
>
> Or is that a silly idea?
>
> Sebb
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
"It's good to be a lunatic..." -- 10th doctor
I don't see it as splitting the community, rather as an adjunct to the
existing community.
One of the reasons would be to allow independent release cycles.
Also, not every user would need all the plugins.
Perhaps this could be done by rearranging the JMeter project, but it
seems cleaner to have a separate repository - as is done with Maven.
S
On 06/10/2007, Henning Schmiedehausen
> Any particular reason, why this can not be a part of the JMeter project?
> Splitting a rather small community into two parts (apache + codehaus)
> does not sound too good. Having that plugin inside the JMeter project
> might lead to new hands helping out with JMeter itself.
>
> Gaining gravity in the project is IMHO a good thing. You might want to
> move TLP at some distant point in the future.
>
> Best regards
> Henning
>
>
> On Sat, 2007-10-06 at 13:27 +0100, sebb wrote:
> > JMeter has just been offered a Maven plugin for creating reports.
> >
> > Rather than include the code in JMeter, I think it would be better
> > hosted at mojo.codehaus.org, along with the other Maven plugins.
> >
> > That got me thinking - perhaps a similar idea could be set up for
> > JMeter plugins?
> >
> > Or is that a silly idea?
> >
> > Sebb
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> --
> Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
> Open Source Consulting, Development, Design | Velocity - Turbine guy
>
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
> Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
>
> "It's good to be a lunatic..." -- 10th doctor
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Hm,
why shouldn't it be possible to do two independent products (JMeter +
Maven Plugin) on different release cycles in one project? Other projects
do this all the time (e.g. Turbine for a very long time with all the
Fulcrum stuff, META etc).
Still no need for a split for me.
Best regards
Henning
On Sat, 2007-10-06 at 14:18 +0100, sebb wrote:
> I don't see it as splitting the community, rather as an adjunct to the
> existing community.
>
> One of the reasons would be to allow independent release cycles.
>
> Also, not every user would need all the plugins.
>
> Perhaps this could be done by rearranging the JMeter project, but it
> seems cleaner to have a separate repository - as is done with Maven.
>
> S
> On 06/10/2007, Henning Schmiedehausen
> > Any particular reason, why this can not be a part of the JMeter project?
> > Splitting a rather small community into two parts (apache + codehaus)
> > does not sound too good. Having that plugin inside the JMeter project
> > might lead to new hands helping out with JMeter itself.
> >
> > Gaining gravity in the project is IMHO a good thing. You might want to
> > move TLP at some distant point in the future.
> >
> > Best regards
> > Henning
> >
> >
> > On Sat, 2007-10-06 at 13:27 +0100, sebb wrote:
> > > JMeter has just been offered a Maven plugin for creating reports.
> > >
> > > Rather than include the code in JMeter, I think it would be better
> > > hosted at mojo.codehaus.org, along with the other Maven plugins.
> > >
> > > That got me thinking - perhaps a similar idea could be set up for
> > > JMeter plugins?
> > >
> > > Or is that a silly idea?
> > >
> > > Sebb
> > >
> > > ------------------------------------------------------------ ---------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> > --
> > Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
> > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
> > Open Source Consulting, Development, Design | Velocity - Turbine guy
> >
> > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
> > Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
> >
> > "It's good to be a lunatic..." -- 10th doctor
> >
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
"It's good to be a lunatic..." -- 10th doctor
On 10/6/07, sebb
> JMeter has just been offered a Maven plugin for creating reports.
>
> Rather than include the code in JMeter, I think it would be better
> hosted at mojo.codehaus.org, along with the other Maven plugins.
Agreed.
> That got me thinking - perhaps a similar idea could be set up for
> JMeter plugins?
>
> Or is that a silly idea?
Maven plugins are glue, plugging anything out there into the Maven
system and so need a certain agility with respects to license - thus a
non-ASF site. So chiefly I think it comes down to license - is it
strongly likely that there will be lots of plugins that need non AL
2.0 licensing?
Hen
Hi Sebastian,
sebb wrote:
> I don't see it as splitting the community, rather as an adjunct to the
> existing community.
>
> One of the reasons would be to allow independent release cycles.
>
> Also, not every user would need all the plugins.
>
> Perhaps this could be done by rearranging the JMeter project, but it
> seems cleaner to have a separate repository - as is done with Maven.
HttpComponents is also managing currently two components on
separate release cycles. However, that comes with a certain
overhead. At the current frequency of our releases, I can
fully understand Oleg's reluctance against putting more modules
on separate release cycles.
If the idea is to have each extra JMeter plugin on a separate
release cycle, you're probably better off without the Apache
overhead. I assume Codehouse does not require three PMC votes
for a release? If the extra JMeter plugins are meant to share
on release cycle, and there are no licensing issues, I believe
it can be handled at Apache.
cheers,
Roland
On Sun, 2007-10-07 at 10:20 +0200, Roland Weber wrote:
> Hi Sebastian,
>
> sebb wrote:
> > I don't see it as splitting the community, rather as an adjunct to the
> > existing community.
> >
> > One of the reasons would be to allow independent release cycles.
> >
> > Also, not every user would need all the plugins.
> >
> > Perhaps this could be done by rearranging the JMeter project, but it
> > seems cleaner to have a separate repository - as is done with Maven.
>
> HttpComponents is also managing currently two components on
> separate release cycles. However, that comes with a certain
> overhead. At the current frequency of our releases, I can
> fully understand Oleg's reluctance against putting more modules
> on separate release cycles.
> If the idea is to have each extra JMeter plugin on a separate
> release cycle, you're probably better off without the Apache
> overhead. I assume Codehouse does not require three PMC votes
> for a release? If the extra JMeter plugins are meant to share
> on release cycle, and there are no licensing issues, I believe
> it can be handled at Apache.
The MyFaces project has a number of custom maven plugins it uses to
build itself. These live in the same project, just like the maven
projects that make up the myfaces core.
They are released on their own lifecycle and this seems to be working
fine.
If the plugins are closely coupled with jmeter then it seems sensible to
me to just manage them as part of the jmeter project.
Regards, Simon
Mojo plugins start out in the sandbox and need 3 votes from current committers to promote to proper.
If you want to release a vote is expected to happen (I think apache voting rules apply)
Mvgr,
Martin
Roland Weber wrote:
> Hi Sebastian,
>
> sebb wrote:
>> I don't see it as splitting the community, rather as an adjunct to the
>> existing community.
>>
>> One of the reasons would be to allow independent release cycles.
>>
>> Also, not every user would need all the plugins.
>>
>> Perhaps this could be done by rearranging the JMeter project, but it
>> seems cleaner to have a separate repository - as is done with Maven.
>
> HttpComponents is also managing currently two components on
> separate release cycles. However, that comes with a certain
> overhead. At the current frequency of our releases, I can
> fully understand Oleg's reluctance against putting more modules
> on separate release cycles.
> If the idea is to have each extra JMeter plugin on a separate
> release cycle, you're probably better off without the Apache
> overhead. I assume Codehouse does not require three PMC votes
> for a release? If the extra JMeter plugins are meant to share
> on release cycle, and there are no licensing issues, I believe
> it can be handled at Apache.
>
> cheers,
> Roland
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>