RE: Publishing to Maven Central
I'm in the progress of writing my second attempt at providing a working maven solution which you can see here: 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. 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. -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
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+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7c.DeploySnapshotsandStageReleaseswithAnt [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.html [7] http://stackoverflow.com/a/5115447
buildbot success in ASF Buildbot on jmeter-nightly
The Buildbot has detected a restored build on builder jmeter-nightly while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/jmeter-nightly/builds/108 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: hemera_ubuntu Build Reason: The Nightly scheduler named 'jmeterNightly' triggered this build Build Source Stamp: [branch jmeter/trunk] HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
Re: Publishing to Maven Central
On 17 January 2012 21:59, Ian Brandt wrote: > > Greetings, > > I'm shifting discussion to here from "Bug 49753 - Please publish jMeter > artifacts on Maven central repository" [1]. > > Considering an outright switch to Maven is a no go [2], 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. > what do developers think about delegating dependency management in the JMeter > Ant build to the Maven Ant Tasks or Apache Ivy? The primary benefit would be > that POMs could be generated to satisfy Bug 49753 that would be based on the > same dependencies used by Ant to compile and execute tests. JMeter dependencies don't tend to change very frequently, so the question is: is the effort required to introduce Ivy/MAT worth it? > Using Ivy as an example (the Maven Ant Tasks have synonymous functionality), > the change would roughly entail the following: > > - Dependency information in build.properties would move to a corresponding > ivy.xml [3] file. > - The _process_all_jars Ant target and friends would be implemented with the > Ivy resolve [4] and retrieve [5] tasks. > - Corresponding classpaths would be generated with the cachepath [6] task. > - Equivalent POMs would be generated with the makepom [7] task. > - JMeter JARs would be published to Nexus [8] with the publish [9] task. I assume that the main build and release procedures would be unaffected? Is that correct? Does Ivy generate source jars? Javadoc jars? If so, what configuration is needed? Can the config be re-used for the compilation phase? > Regards, > > Ian > > > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=49753 > [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50324 > [3] http://ant.apache.org/ivy/history/2.2.0/ivyfile.html > [4] http://ant.apache.org/ivy/history/2.2.0/use/resolve.html > [5] http://ant.apache.org/ivy/history/2.2.0/use/retrieve.html > [6] http://ant.apache.org/ivy/history/2.2.0/use/cachepath.html > [7] http://ant.apache.org/ivy/history/2.2.0/use/makepom.html > [8] https://issues.apache.org/jira/browse/INFRA-4332 > [9] http://ant.apache.org/ivy/history/2.2.0/use/publish.html >
Publishing to Maven Central
Greetings, I'm shifting discussion to here from "Bug 49753 - Please publish jMeter artifacts on Maven central repository" [1]. Considering an outright switch to Maven is a no go [2], what do developers think about delegating dependency management in the JMeter Ant build to the Maven Ant Tasks or Apache Ivy? The primary benefit would be that POMs could be generated to satisfy Bug 49753 that would be based on the same dependencies used by Ant to compile and execute tests. Using Ivy as an example (the Maven Ant Tasks have synonymous functionality), the change would roughly entail the following: - Dependency information in build.properties would move to a corresponding ivy.xml [3] file. - The _process_all_jars Ant target and friends would be implemented with the Ivy resolve [4] and retrieve [5] tasks. - Corresponding classpaths would be generated with the cachepath [6] task. - Equivalent POMs would be generated with the makepom [7] task. - JMeter JARs would be published to Nexus [8] with the publish [9] task. Regards, Ian [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=49753 [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50324 [3] http://ant.apache.org/ivy/history/2.2.0/ivyfile.html [4] http://ant.apache.org/ivy/history/2.2.0/use/resolve.html [5] http://ant.apache.org/ivy/history/2.2.0/use/retrieve.html [6] http://ant.apache.org/ivy/history/2.2.0/use/cachepath.html [7] http://ant.apache.org/ivy/history/2.2.0/use/makepom.html [8] https://issues.apache.org/jira/browse/INFRA-4332 [9] http://ant.apache.org/ivy/history/2.2.0/use/publish.html
