On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar <[email protected]>wrote:
> On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien <[email protected]> > wrote: > > On Nov 25, 2010, at 2:29 PM, Peter Lin <[email protected]> wrote: > > > >> even though I haven't been active in jmeter in a while, I am still a > >> jmeter committer. > >> > > > > Quantify "a while". > > > <snip/> > > No need, we have archives for the curious. > > > > I'm still a committee on various projects. Would I veto a change by > someone with a defined need who shows initiative? No. > > > > If Peter Lynch has the itch, why not let him experiment? This place > works on initiative, not a series of subjective objections to a tool he > wishes to use. > > > > This place works only if people like yourself (like myself) get out of > the way of people more active than ourselves. > > > <snap/> > > All good above. > > Finally, the onus is on those who experiment to convince those who do > the work here that the proposed changes are then worthy. > > +1 As one data point for a potential contributor, I will share the following. I have been lurking on this list for quite some time and intending to eventually propose some ideas/patches for enhancements. Seeing this thread, i thought it would be a good idea to see how hard it was for me to get set up to build the code and run the tests. The answer is it took me about 10 minutes, which is frankly less time than most maven-built projects take to get going and *way less* than any nontrivial maven build. I particularly like that there is a README as well as a building.html that clearly describe the simple steps necessary to get set up. If you follow the directions to download the dependent jars and replace the Eclipse .classpath file with eclipse.classpath, Eclipse is fully set up. I did not try to actually run anything from within Eclipse, as I find that is in general a bad idea for anything nontrivial; but the nicely documented ant build.xml worked for me out of the box. It was impressive to me that I did not have to fuss with any local property settings, given the amount of config that Jmeter and its tests use. [I did get the following test failure: [java] 1) runSerialTest(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError: serialization of org.apache.jmeter.functions.gui.FunctionHelper failed: java.io.NotSerializableException: com.apple.laf.AquaComboBoxUI Looks Apple-specific. I am running java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)] Two of the ten minutes were spent fussing with Eclipse because I had replaced the classpath before downloading the jars. Closing and reopening the project was not enough to get Eclipse to stop thinking the jars were "missing." I had to recreate it after the jars were in place. It might be better to change the instructions to remind people to download the jars before creating the Eclipse project. I can submit a patch for that if others agree this is a good idea. So I am personally finding it hard to believe that mavenizing the build is really going to make it easier for people to get involved with Jmeter. If there are Jmeter artifacts of general usefulness, I think it would be a *good thing* to develop either Ant or Maven targets to get them published. That would be a much easier task than trying to get the full Jmeter build working in Maven. I agree strongly with Rahul and Peter Lin though that this decision belongs to them who do the work. Phil > -Rahul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
