On 18 January 2012 22:45, Mark Collin <m...@ardescosolutions.com> wrote: > Uploaded a final version just now. > > I had to fix some transitive dependency problems that were not apparent > until you tried to use the artifacts and I had one POM that was not > correctly referencing ApacheJMeter_parent. > > The final version will also automatically download ant-contrib if you don't > have it to make the whole process easier.
I don't think we need the ant-contrib; so long as Maven is locally installed it's possible to access it using Java. I recently committed an Ant script that uses this technique to upload the jars (so far not source or javadoc). > Let me know if it needs any more tweaking. Have you seen the snapshots I uploaded? Do the poms work OK? If not, what needs to be fixed? > Regards > > Mark > > -----Original Message----- > From: Mark Collin [mailto:m...@ardescosolutions.com] > Sent: 18 January 2012 14:10 > To: dev@jmeter.apache.org > Subject: RE: Publishing to Maven Central > > I was trying to find a way that would use a unified dependency list for both > the ant build and the maven deploy. > > The path I have been going down is creating a dependency POM for doc, core > and api and making them required dependencies of ApacheJMeter_parent. I > have then modified build.xml to use these dependencies instead of > build.properties, but I'm running into issues with the existing classpath > declaration in the build.xml because it doesn't just use all of the files in > core, doc, or api. > > I'll upload what I currently have > > > -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: 18 January 2012 12:41 > To: dev@jmeter.apache.org > Subject: Re: Publishing to Maven Central > > On 18 January 2012 12:30, Mark Collin <m...@ardescosolutions.com> wrote: >> It looks like you have specified all of the dependencies in the >> ApacheJMeter_parent pom. >> >> I thought you wanted a unified set of dependencies that are only >> declared in one place. > > Ideally, yes, but that looks to be hard to do. > This approach should be enough to publish the jars and it's not to hard to > maintain. > If it can be improved later, so much the better. > >> The code I have right now will deploy to a repo using ant to call the >> mvn deploy command via an exec command. It's working on Linux and >> Windows and just requires you to have maven installed upon your system. > > Does it use standard Ant? > Can you attach the file to the Bugzilla issue so I can try it? > >> I can add in the dependency list to the parent.pom and it will all >> work > right now. > > Huh? > What's wrong with the existing dependency list in ApacheJMeter_parent pom? > >> -----Original Message----- >> From: sebb [mailto:seb...@gmail.com] >> Sent: 18 January 2012 10:56 >> To: dev@jmeter.apache.org >> Subject: Re: Publishing to Maven Central >> >> 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+Repos >>> i >>> tory+U >>> sage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7c.DeploySnapshotsand >>> sage+S >>> sage+tageRe >>> 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-wit >>> h >>> -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 >> >> -- >> 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 > > -- > 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 > -- > 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 > > -- > 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
