I'm also not a JMeter committer but would second the notion that maven is a PITA, as I've had many runs ins with it in relation to ApacheDS. It seems to take months to setup up all the publishing side of it, and I absolutely cannot accept that you need to do a lot of extra configuration if you want to guarantee the thing you built yesterday will build the same today (at least I've been told it's possible to configure it to allow a stable build). To me that is by far the most crucial aspect of a build system, and auto-downloading of jars etc is merely a nice to have.
I started out with an open mind about Maven, but now I think it is at best mis-configured OOTB and at worst a bit misguided. Also note that changing the source repository has a very bad effect on people that are maintaining custom patches, like me, as they can no longer do "svn diffs". Norval On Fri, Sep 19, 2008 at 2:58 AM, Peter Lin <[EMAIL PROTECTED]> wrote: > I should state I am bias against maven. I believe getting jmeter to > work with maven is feasible, but the cost of maintaining is going to > be high. Although you can override the default directory structure, > maven works best if you follow their "conventions". > > Since I don't actively work on jmeter these days I won't vote against > it, but maven doesn't live up to the hype. I find it works well for a > new project with simple dependencies. JMeter is a bit complex from a > build perspective, since we use some jars that are not included in the > build. Also, we tend to build components in a specific order, which > isn't maven's strong point. > > peter > > > On Thu, Sep 18, 2008 at 12:53 PM, sebb <[EMAIL PROTECTED]> wrote: >> On 18/09/2008, Tomasz Pik <[EMAIL PROTECTED]> wrote: >>> On Sat, Jul 19, 2008 at 3:21 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> >>> wrote: >>> > Sebastian >>> > >>> > If you ever decide to port JMeter to Maven I will be willing to give you >>> > a helping hand with that. We could still use the existing scripts to >>> > build the distribution packages and generate the web site. It would be >>> > beneficial, though, at least in my opinion, to use Maven to manage >>> > dependencies and compile JMeter. >>> >>> >>> Would it be possible to change directory structure of JMeter source tree >>> a little, so it will be more 'maven friendly'? >>> One change needs to be done - in directories with source code >>> (like src/components) there should be at least one more level: >>> src/components/java. >>> Then there'll be natural place for pom.xml files: >>> src/components/pom.xml >>> src/components/java/org/apache/.... >>> Ideally, it should be src/components/src/main/java >>> (OR components/src/main/java, with getting rid of top level >>> src directory but I do not know if such a change would >>> be acceptable to JMeter developers). >>> Is there a chance to make such a change? >> >> The existing directory structure is not set in stone - it was changed >> a year or two ago to move the test files into a separate directory >> tree. >> >> However I don't think we should start on changing JMeter directory >> structure in SVN until we are sure that the end result will work for >> Maven. >> >> My personal view is that Maven should not be so picky about directory >> structures, but so long as JMeter can still be built and tested using >> Ant then I don't see a problem with moving the various chunks of the >> source code tree around. >> >> I just don't think it makes sense to start on that process and then >> find that there is some other aspect of the JMeter build process that >> is not supported by Maven. For example there are three output >> directories for jars (bin, lib, lib/ext) and lots of different jars. >> >>> >>> Regards, >>> Tomek >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
