â¦ Python, etc. The implementation is incomplete, please comment.
I put extraneous stuff in `attic` subdirectory for reference.
`release/upload.xml` could very well be integrated in build.xml (because of `project.version`).
`fetch.xml` does not implement all targets nor updating Ivy distribution
(could be done by restricting ivy:resolve to a particular conf). ð

As I've preformed a few releases myself let me start by telling you that I have run `fetch.xml` when we upgraded BCEL but usually don't use it at all as my workspace already contains everything I need to build a release.

I have never used `build-osx-pkg.py` (and am not aware of anybody ever using it, `buildosxpackage` has never been true for me and there is no `pkg` file in http://archive.apache.org/dist/ant/binaries/) or `signit.xml` (as I prefer to use the command line for that, I think Antoine has used it in the past).

As I usually am not an Ivy user I'd prefer my everyday build of Ant to not require me to place Ivy on the CLASSPATH, I'm totally content with not integrating upload with the normal build process as uploading is a very rare exceptional use case only ever performed by a single person. But that's just my preference, YMMV.

I would like to point out one distinction: I would like to replace the stuff that works (sort of) with **less** stuff that does the same job, and hopefully more. Besides, my beef with Maven Ant tasks was that they morphed into Aether Ant tasks, and then Maven Resolver Ant tasks and changed syntax along the way, and I couldn't add Bintray using Maven Ant tasks (at least in a nontrivial way).

`buildoxspackage` is a requested feature, and it does no harm to keep it, albeit in a simple native implementation.

The point with `signit.xml` is that Ivy does it all in one go with `upload.xml` and with less stuff in `ivy.xml`

I can change `fetch.xml` so that release conf goes into a separate place, and so Ivy + BouncyCastle are kept out of sight (unlike Maven Ant tasks).

I didn't suggest to remove the `buildosxpackage` feature, just that you are putting quite a bit of effort into an area that is probably never used - at least not much.

As I said, I don't use `signit` at all and I do not want to give the passphrase to my PGP key on the command line. As long as I can keep using the gpg command line and Ivy will then upload the signatures I've created, I'm fine with it.

`buildosxpackage` was peanuts compared to getting rid of `root` system property kludge for surefire in tests.

BTW, Ivy `signer` saves you work with

1. signing in advance
2. having to declare all signatures in `ivy.xml`
3. publishing extraneous checksums for signatures

I'd rather add another ivy.xml for distributions that would use filesystem resolver to publish signed distributions into the svn repo... [svn resolver](https://github.com/massdosage/ivysvn) for Ivy seems a bit of an overkill.

For the changes you plan to introduce to the release process I urge you to not change things just because they look better to you. As it stands I'd be your main user and I'm fine with the process as it is and am completely happy with signing artifacts manually (which happens whenever I cut a release, so twice every few months at best).

Our Nexus is going to create extraneous checksums anyway, no matter what Ivy does. Not sure about your second point (I don't declare anything anywhere). You are completely losing me when you talk about the svn resolver, I don't see any reason to use Ivy in order to publish artifacts to dist.apache.org at all.

I am very well aware of your role. I hope we agree about KISS or continuous improvement, though.

In particular, regarding the second point, please compare `release/ivy.xml` with `ivy.xml` (too bad the diff is so huge that Git thinks they're two different files). The price of simplification to pay, so to speak, is signing while uploading. If you're not willing to discuss that, we can leave the whole upload discussion out and only focus on fetch. However, there is one more point with distributions (zip and tar), if you bear with me.

It is my understanding of the release process that distributions are manually copied and checked into Subversion. My point was that the process could be better documented by creating an extra ivy.xml which would be used by upload (or upload-like) process and thus be semi-automated.

TBH I don't really care for the content of a write-once Ivy file much, but that may be just me. Maybe I'm (a bit) old-fashioned, I actually really want to upload files to Nexus and svn manually rather than automate this, as this is the step where I personally verify all artifacts one more time before calling for a vote.

We probably should move the upload discussion to the dev list and really focus on the fetch part here.