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 > On Thu, Nov 25, 2010 at 2:56 PM, Tim O'Brien <tobr...@discursive.com> > wrote: > > This community is a Meritocracy, not a Democracy. "What's the > difference?", you ask. > > > > In a Democracy you have a vote, you can cast your vote for various > reasons, no one asks "why" if you vote a certain way. There's no abstract > idea of "merit". > > > > At Apache you certainly have a "vote" in a consensus-based approach to > collaboration, but no one has license to -1 without an argument "on the > merits". This is what makes the community a Meritocracy. If you disagree > with Peter's initiative, you'll need to provide a few things for your veto > to "stick": > > > > 1. A detailed set of objections to which Peter should be able to respond. > > > > 2. Some justification as to why the community would reject initiative? > > > > 3. A reasonable attempt to understand the merit of a particular proposal. > > > > I think the "maven is a road to hell" rhetoric violates the necessary > sense of decorum that enables a group of volunteers to work together. It > runs counter to the ideas the Foundation (supposedly) adheres to. > > > > If you are really casting a veto on peter's initiative stand up and > present a viable counter-argument. If you don't I do believe the the > community should disregard you previous email. > > > > Tim O'Brien > > > > > > On Nov 25, 2010, at 12:46 PM, Peter Lin <wool...@gmail.com> wrote: > > > >> > >> I hate maven and it sucks. It does not reduce maintenance at all. I vote > against changing to maven. > >> > >> -1 > >> > >> Maven is a road to he'll on my book > >> > >> Sent from my iPhone > >> > >> On Nov 25, 2010, at 1:28 PM, sebb <seb...@gmail.com> wrote: > >> > >>> On 25 November 2010 17:54, Peter Lynch <pe...@peterlynch.ca> wrote: > >>>> Hi sebb, > >>>> > >>>> On Thu, Nov 25, 2010 at 9:42 AM, sebb <seb...@gmail.com> wrote: > >>>> > >>>>> On 25 November 2010 14:18, Peter Lynch <ply...@apache.org> wrote: > >>>>>> I am wondering if there is developer support for the idea of > converting > >>>>>> JMeter's build process to be based on Maven. If there is suitable > support > >>>>> of > >>>>>> this idea, I was going to start writing a conversion script that > would > >>>>>> convert the project sources while maintaining as much scm history as > >>>>>> possible. > >>>>> > >>>>> Should be possible to maintain all SCM history if done properly. > >>>>> > >>>>> Note that changes of source layout will cause a (one-off) problem for > >>>>> people who maintain private patches. > >>>>> > >>>>>> I have outlined some of the advantages this offers in this > enhancement > >>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50324 > >>>>>> > >>>>>> <https://issues.apache.org/bugzilla/show_bug.cgi?id=50324> > >>>>>> So what do the developers think? > >>>>> > >>>>> Why do you want to build JMeter with Maven? > >>>>> > >>>>> > >>>> I'd like JMeter to be accessible to as many developers as possible. > I'd like > >>>> the source code layout to be more standardized, to be more accessible > to > >>>> Java developers who want to contribute to the project. I'd like to fix > >>>> problems in JMeter source code by opening the project in any IDE that > >>>> supports Maven project structures and know instantly how to run tests, > build > >>>> and deploy. I'd like the artifacts that JMeter produces to be in a > format > >>>> that can be more easily reused and referenced by other projects. > >>>> > >>>> > >>>>> Is it just so that JMeter jars can be uploaded to Maven Central? > >>>>> If so, then there are simpler ways to achieve this. > >>>>> > >>>>> > >>>> No that is not the primary reason, see above. I am familiar with how > to get > >>>> jars on Central using various methods - I work at Sonatype afterall > ;). > >>>> > >>>> Is it so that you can run JMeter with Maven (assuming jars are in > Central)? > >>>> > >>>> If so, then potentially major changes are needed to JMeter, because > >>>>> currently it maintains its own classpath, and expects to find jars in > >>>>> specific locations. > >>>>> For example, lib/ext is searched for JMeter components; lib is not. > >>>>> Since JMeter has to do quite a lot of jar scanning, it is important > >>>>> that this is efficient. > >>>>> > >>>> > >>>> You bring up some good points but all of this is scope creep - it may > come > >>>> as an eventual side effect but that is not the main goal. > >>> > >>> This is not scope creep - if the above mentioned issues are not > >>> addressed, then JMeter either won't work or will be slowed down. > >>> > >>>> It may turn out > >>>> that during the conversion process there is some roadblock that would > >>>> prevent Maven being useful - but I doubt it. > >>> > >>> Well, the above need to be addressed for a start. > >>> > >>>> I would suggest any changes > >>>> converting to Maven brings affects mostly project structure, > accessibility > >>>> and maintainability over the long term. > >>> > >>> The layout of SVN is not particularly important to me; that can be > >>> changed to suit Maven and the Ant file modified to suit. > >>> > >>> However, I do take issue with the proposition that converting to Maven > >>> necessarily reduces maintenance. > >>> > >>>>> > >>>>> Note also that the Ant build does some work that may be tricky to > >>>>> implement in Maven. > >>>>> For example, the documentation is built twice - once for web-site, > and > >>>>> once for the dynamic help system. > >>>>> The build also creates a lot of different jars. > >>>>> My experience of multimodule Maven builds is that they can take a lot > >>>>> longer than Ant, and are tricky to get working correctly. > >>>>> > >>>>> I'm not saying that JMeter can't or won't use Maven for builds, but > >>>>> it's not going to be at all easy to implement and maintain. > >>>>> I know from my participation in Apache Commons that even simple > >>>>> projects can spend quite a lot of time on Maven issues. > >>>>> > >>>>> > >>>> It sounds like you have some valuable experience to draw upon. That's > great! > >>> > >>> I'm the current release manager, and have been for several years. > >>> > >>>> As long as there is not a defacto no to experimenting using Maven then > I > >>>> suggest to come up with a script first that does the conversion, and > then > >>>> discuss if the end result tradeoffs make JMeter a better project or > not (... > >>>> and if the changes the script applies should get committed). > >>> > >>> Rejigging the source files to fit in with Maven is a one-off effort, > >>> but before starting down this road, I think someone needs to show that > >>> JMeter will actually run OK when the jars are stored in a Maven repo. > >>> > >>> That should be possible to prove without needing to make any changes > >>> to the JMeter source layout. > >>> AIUI, it would just require copying the jars and basic POMs to a local > >>> repo, and creating a POM that depends on the JMeter jars. > >>> > >>> This work would not be wasted, as the POMs that are created will be > >>> needed later in the Mavenisation of JMeter (assuming the experiment is > >>> successful). > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > >>> For additional commands, e-mail: dev-h...@jakarta.apache.org > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > >> For additional commands, e-mail: dev-h...@jakarta.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > > For additional commands, e-mail: dev-h...@jakarta.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > >
