hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Discuss: automate staging of tarballs (packages)
Date Fri, 14 Jun 2013 18:01:40 GMT
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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message