On 18 January 2012 06:35, Mark Collin <m...@ardescosolutions.com> wrote: > I'm in the progress of writing my second attempt at providing a working > maven solution which you can see here:
It looks to me like an Ant build script using Maven deploy, i.e. Maven is not used for building. > https://github.com/Ardesco/jmeter/tree/trunk/maven > > The sticking point I have at the moment is plugging in the dependencies, I > have been looking at tweaking the existing ant script to use > maven-ant-tasks, this is how far I have got (It doesn't work yet): > > https://github.com/Ardesco/jmeter/blob/trunk/build.xml > > Downloading the dependencies is trivial, however finding a nice way to > specify individual jars for the classpaths and the release mechanism is not > quite so tidy, the most sane way would seem to be a series of POM files to > set the dependencies for each requirement but I'm not sure if that is > changing the existing build process too much. Ant does not care about the dependencies being distributed accurately, so long as all the dependencies are present. AFAIK Maven need not either; if the parent depends on all the 3rd party libs, then every JMeter jar can depend on the parent. Intra-module dependencies in JMeter are quite simple and don't (generally must not) change. > Today I was planning on having a look at building some dependency POM's for > the maven deploy on the fly from the build.properties as maybe a saner way > to do things which will won't touch the existing build.xml at all, although > I'm not that happy with this solution either. Have you seen the POMs I comitted ro res/maven yesterday? I was planning on using Maven deploy to upload them to a SNAPSHOT repo. Someone can then see if the result is usable. > > -----Original Message----- > From: Ian Brandt [mailto:i...@ianbrandt.com] > Sent: 18 January 2012 05:04 > To: dev@jmeter.apache.org > Subject: Re: Publishing to Maven Central > > > On Jan 17, 2012, at 4:10 PM, sebb wrote: > >> IMO Maven works well for some projects, particularly single component >> (module) builds. >> Multi-module Maven does not work as well; in particular the test phase >> requires the project to be (re)installed first. > > Understood. I like Steve Ebersole's writeup of such issues he encountered > with Hibernate [1]. On the other hand I maintain a 20 module Maven build at > my company, having converted it from Ant a few years back, and have no > regrets and minimal issues. > >> JMeter dependencies don't tend to change very frequently, so the >> question is: is the effort required to introduce Ivy/MAT worth it? > > Good question, I can only offer anecdote. > > Before moving my company's build to Maven I first tried the Maven Ant Tasks > and then Ivy. The situation was that we had a large (50+) and frequently > changing list of direct and transient dependencies. With no way to > comprehend all the relationships it was proving a maintenance nightmare to > not use a dependency manager. MAT proved lacking in needed functionality at > the time, so that attempt was short lived. With Ivy I can't remember the > specifics, but I remember hitting enough issues and struggling with the > documentation such that one day I just gave up and switched the entire build > to Maven. I'd have to say that for either MAT or Ivy to be worth it they'd > need to have matured since then. It's encouraging to see there is now > Sonatype and Apache documentation on publishing to Maven repositories with > them: [2], [3]. > > If JMeter has a small and unchanging set of dependencies then the situation > is different. I'd only add that with any dependency management system the > correctness of the declared relationships is everything, and with Maven you > generally get one chance to get it right when publishing a given version to > Central. Tomcat has fewer external dependencies than JMeter I believe, and > yet in my experience the Tomcat POMs aren't always right. I'm proposing > that MAT or Ivy might lead to higher quality POMs being published by JMeter > because the exact same dependency information would be used to compile and > test beforehand. > >> I assume that the main build and release procedures would be unaffected? >> Is that correct? > > I've looked oven the Ant build, the README, and the Release Creation > document on the Wiki [4]. Nothing jumps out as likely to be affected by MAT > or Ivy that wouldn't already be involved with publishing to Maven in general > [3]. > >> Does Ivy generate source jars? Javadoc jars? >> If so, what configuration is needed? >> Can the config be re-used for the compilation phase? > > > No, that'd still all be up to the traditional Ant tasks. MAT or Ivy would > reference these Jars however, and publish them along with the main > artifacts. See Attaching Multiple Artifacts in the MAT documentation [5], > or the examples in these how-to's for Ivy: [6], [7]. > > Ian > > > [1] https://community.jboss.org/wiki/GradleWhy > [2] > https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U > sage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7c.DeploySnapshotsandStageRe > leaseswithAnt > [3] http://www.apache.org/dev/publishing-maven-artifacts.html#ant > [4] http://wiki.apache.org/jmeter/ReleaseCreation > [5] http://maven.apache.org/ant-tasks/examples/install-deploy.html > [6] > http://draconianoverlord.com/2010/07/18/publishing-to-maven-repos-with-ivy.h > tml > [7] http://stackoverflow.com/a/5115447 > > -- > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. > > If you have received this email in error please notify > postmas...@ardescosolutions.com
