Peter Lin,

On Thu, Nov 25, 2010 at 10:49 PM, Peter Lin <wool...@gmail.com> wrote:

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

Obviously I did not suggest JMeter will die if it doesn't use Maven ?? Where
in the world...


> 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?
>
>
I'm just suggesting that it is convenient to load a project's sources into a
modern IDE and have the IDE instantly know how to build the project without
setting up anything. That I can use previous knowledge of working on other
projects and reuse it with this one. That it is useful for a project to
share it's artifacts with others in a standard way. That someone who wants
to contribute a patch or fix a bug or write a test has a lower barrier to
entry.

I've already stated other benefits in previous messages and in the bugzilla
issue.

Don't worry - I'm not launching JMeter Inc.

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.
>
>
Is it really necessary to use terms like 'road to hell', describe some ideas
as 'stupid', imply suffering and burdens.  Perhaps it may cause some people
to ignore your experiences and opinions and focus instead on your generally
poor demeanor. I'm not seeing how it helps your arguments.

At the end of the day, I'm just looking to volunteer my time to add value to
a project I use. I am not here to sell Maven like snake oil.

I refuse to predict how great or horrible JMeter will become if it uses
Maven - I'd rather spend time writing a conversion script to at least
provide the option for factual evaluation.

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

Reply via email to