On Fri, 2013-06-14 at 19:01 +0100, sebb 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]. >
Sebastian Feel free to use whatever tooling you deem the best for the job. Anything that can make current process easier would be very welcome. I looked into Gradle as a possible candidate for a release automation tool but found the amount of effort involved in migrating current web content generated by various maven plugins to a different framework pretty much prohibitive. Oleg > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
