so far I am not convinced of the benefits of changing to maven. my vote is still -1
As I said before, my feeling is jmeter is mature and stable. JMeter isn't missing any critical features and seb has done a phenominal job of maintaining it. It's not like there's 10 critical features JMeter must have. Frankly, I don't buy the argument that jmeter will die. Given JMeter's focus is narrow, there's no point bloating it with lots of useless knobs and buttons. I also don't buy the argument of building developer community. JMeter's developer list has always been small even before I joined. I attribute this to the focused nature of jmeter. JMeter doesn't try to be the kitchen sink, butler, maid, dumb waiter, door bell, race car and bus all rolled into one. What kind of improvement are you talking about? What kind of growth are you talking about? Performance tools have a nitch and will always be that way. There's no realistic way to drastically grow jmeter's user base. Even though the traffic on the mailing list doesn't show it, the user base is much larger. Before I joined jmeter, I thought the user base was small. Once I started hearing from users directly, it became apparent the user base is much larger. For example, I know aetna uses it across their enterprise and is officially recommended by their standards and practices group. That's a huge user base in just 1 health care company. I also know the university of connecticut uses jmeter as their standard testing tool. What's the difference between running ant vs build command? What's the cost vs time benefit for switching? I won't speak for sebastian, but my experience is that maven 1 & 2 aren't reliable. If sebastian is ok with the change, I'm ok with it. He is the one who has been actively maintaining it and he is the one who will have to suffer maven. Long after other developer leave, sebastian will probably be the one maintaining it. My suggestion is to think of sebastian and the burden you put on him. Don't arbitrarily change the build because you happen to love maven. On Thu, Nov 25, 2010 at 9:21 PM, Peter Lynch <ply...@apache.org> wrote: > Truthfully the main motivation for proposing to use Maven to build JMeter is > to increase the chances of getting more people involved in the project, to > fix bugs, to send patches and add features. > > Honestly do we expect the majority of potential developers to run for the > hills and the project to die if JMeter project is built with Maven? > > > On Thu, Nov 25, 2010 at 3:29 PM, Peter Lin <wool...@gmail.com> wrote: > >> even though I haven't been active in jmeter in a while, I am still a >> jmeter committer. >> >> quite honestly, I've seen maven work first hand. >> >> 1. the claim it reduces maintenance has not truth. My first hand >> experience is that it creates a much bigger burden. >> >> > Configuration management maintenance burden is relative to the frequency of > change within the project. If what JMeter delivers in terms of final > artifacts does not change, I don't expect maintaining a Maven build to > somehow require change for change sake. > > 2. changing the directory structure of jmeter to fit maven is wrong >> for several reasons. due to maven's "suggested structure" it's common >> to run into path length issues on windows platforms. When i was >> responsible for maintaining maven builds, we often had to rename unit >> tests because it exceeded 255 characters. Forcing everyone to use and >> build on linux or unix is not acceptable in my book. >> >> > Using an NTFS based Windows file system, UNC paths, path name components > (ie. a file name or directory name) under 260 characters and total path > length under ~32000 characters - there is no problem. > > Last I experienced a problem using Maven and long paths was with > JDK 1.5, Windows XP and a FAT filesystem. How many developers are building > JMeter on a FAT filesystem, I dunno but sounds like the chances of running > into this problem on a development environment nowadays is pretty slim. > > > >> 3. not everyone wants or cares to install maven. >> >> Couldn't someone say that about any tool? > > >> 4. maven 1 and 2 are both slow >> >> > We cannot compare speed of the building JMeter using Maven because we have > no benchmark building it with Maven yet. > > We create a script that converts to Maven project. Run the build actions > and understand the deployment process. Compare the build time it takes to do > common actions. Weigh any build time overhead with current build process and > all of the other benefits and go from there. Lets say the entire Maven build > takes 10 seconds longer (I have no data yet) - is it so bad that all the > other benefits make it not worth it? If how to develop JMeter using IDEA, > Netbeans and Eclipse remains a black art compared to just importing a Maven > project into your IDE and go...is it worth it? Maybe...but lets at least > deal with facts at least. The first step to do that is to try it out. > > >> 5. maven repositories are notoriously unreliable. when maven >> repositories go down, maven builds fail until that repository comes >> back. A few years back codehaus went down due to hardware failure. >> people that relied on codehaus + maven ended up having build issues >> >> > The state of repository servers has changed quite a bit from a few years > ago. > > 6. maven 1 & 2 repositories are poorly designed and do not support >> versioning properly from first hand experience. Back when I maintained >> maven builds, we ended up creating multiple maven repositories >> internally so that we could support multiple releases. >> >> > I can say that using Maven 1 is a bad choice today if you have the > opportunity to use Maven 3. Since JMeter would be newly using Maven, I see > no reason not to use the latest version. > > > bottom line is, maven is poorly designed and not worth the hassle. >> Plenty of people find it works fine for them, and there's lots of >> people who love maven. I am not one of those people. >> >> >> > I'm looking to grow the JMeter community. I thought this was one way to help > do that. > > Really does this have to be a opinionated flame war? There are simple people > out there looking to volunteer to help a project grow and improve. I'm > offering to be one of them. > > -Peter > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
