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. So, in general but perhaps not in the case of this project, deploying bin zips/tars to Maven Central would be nice. Gary On Fri, Jun 14, 2013 at 2:01 PM, sebb <seb...@gmail.com> 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: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 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
