hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Discuss: automate staging of tarballs (packages)
Date Fri, 14 Jun 2013 20:10:22 GMT
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-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message