On 14 June 2013 21:23, Gary Gregory <[email protected]> wrote: > This is a tangent: > > Here is an alternative user story that comes from a real work situation. > > In order to use Apache JMeter and Apache ActiveMQ as part of our CI system, > we have put the binary zip of theses projects into our private Artifactory > repository. This let's us use Ivy to automatically download these to each > build machine. Our Ant targets can then install and run JMeter and > ActiveMQ, which is something we cannot do by just getting the jars from > Maven Central.
JMeter also provides Maven jars, but not bundled packages. It's also possible to download directly from the ASF mirrors. > So, in general but perhaps not in the case of this project, deploying bin > zips/tars to Maven Central would be nice. The ASF requires source releases to be made via the mirror system. I don't know whether there is a prohibition on additionallu providing packages via Maven; I suggest you raise this with Infra. And also raise with Maven Central, because providing packages there would roughly double the size of each release > Gary > > > On Fri, Jun 14, 2013 at 2:01 PM, sebb <[email protected]> wrote: > >> The current staging mechanism for tarballs (src & bin packages) is >> quite manually intensive and error-prone (and somewhat unpopular!). >> >> So I've been doing some work trying to simplify/automate the process. >> >> At present the tarballs are generated by the assembly plugin, which by >> default attaches them to the project. >> This means they get signed and hashed along with the jars (which is >> good) but they are also deployed to Nexus with the jars (not so good). >> >> So I suggest detaching the tarballs, and staging them separately. >> >> I think it's important to create the tarballs from the same jar files >> as are deployed to Nexus. >> This means the tarballs need to be created as part of the same release >> process. >> >> The assembly plugin therefore needs to be configured with attach=false. >> I think it would be simpler if the files were created in a separate >> directory - e.g. target/tarballs [or target/packages?] - rather than >> in the rather crowded target/ directory. This can be done with the >> outputDirectory assembly parameter. >> >> Thus at the end of the deploy phase, the Maven jars will have been >> uploaded to Nexus, and the tarballs (only) will be in target/tarballs. >> >> It's then a relatively simple matter to create sigs and hashes for all >> the files in target/tarballs. >> The files can then be uploaded using a generated svnmucc script to >> https://dist.apache.org/repos/dist/dev/ >> >> The RC vote can then take place as usual. >> >> What do you think? >> Does that sound like a reasonable approach? >> >> There are several stages to automate: >> - create sigs and hashes for the tarballs >> - create svnmucc scripts for upload (and eventual release promotion; >> possibly also RC deletion) >> - invoke svnmucc with the appropriate parameters to do the upload (and >> later, release) >> >> Initially I suggest performing these as separate steps following Maven >> deploy, but if things work well, then most (all?) of the stages can be >> integrated into a single Maven invocation. >> >> I've done some experiments, and I think all of the processing can be >> achieved with either a Maven Ant plugin (using BeanShell for >> scripting) or a pure Java Maven plugin. [I started with Ant because I >> was playing with the commons build plugin]. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
