Add support for single-module projects

[abesto]

Fixes #13

This started out simple. :)

First thing I realized was that with the module argument becoming optional (and so an option, as in --module $MODULE), the only remaining positional argument is the version. So for consistency I moved that into a required --version $VERSION option. This is a breaking change.

I wanted to test this against a project without modules. I looked for a likely candidate in the recent VOTE threads on the ASF incubator lists. Ended up choosing Dubbo. Problem is, the filename of the .zip of Dubbo, AND ALSO the directory inside the archive, are not named exactly like their Zipkin counterparts. After hacking around with flags, I decided to do this properly and introduce a little templating for this. As usual, the defaults work for Zipkin. So, testing against Dubbo goes like this:

env BUILD_IMAGE=1 ./check.sh \
    --project dubbo --version 2.7.1 --gpg-key 9C44B5A6884984DB \
    --git-hash a36cc7520e0150d07d30e8baa0c61d5f9f11e6ed \
    --incubating --repo release \
    --zipname-template 'apache-{project}{dash_module}{dash_incubating}-{version}-src' \
    --sourcedir-template 'apache-{project}{dash_module}{dash_incubating}-{version}-src'

Notice the absence of a --module argument.

Running against a Zipkin module:

env BUILD_IMAGE=1 ./check.sh --module brave-cassandra \
    --version 0.10.2 --gpg-key BB67A050 \
    --git-hash b8e379f33eb9f52f0742d3187252de330163cbf7 \
    --repo release

While doing this I noticed that if an intermediate step fails (like unzipping), then down the line we might crash with an exception (like when specifying some non-existent directory as the workdir to run a subprocess). So I also wrapped each check in an exception handler.

[abesto]

(Click provides easy ways to read option values from ENV vars, so down the line users could define their templates in a single location with ENV variables)

[codefromthecrypt]

I suppose the naming template itself could be a parameter (defaulting to what we use heh :))

This comes in time for when our boot layout factory migrates!

[abesto]

I suppose the naming template itself could be a parameter (defaulting to what we use heh :))

I'm not sure I follow - I think this PR does that? Or do you mean we could provide presets? Or something else? Please elaborate / give an example of usage :)

[codefromthecrypt]

you need to work on your mind reading skillz!

sorry I meant I saw repetition, which looked like a naming policy which could be defaulted. Maybe it is an early optimization.

   --zipname-template 'apache-{project}{dash_module}{dash_incubating}-{version}-src' \
    --sourcedir-template 'apache-{project}{dash_module}{dash_incubating}-{version}-src'

[abesto]

sorry I meant I saw repetition, which looked like a naming policy which could be defaulted. Maybe it is an early optimization.

So yeah, there is defaulting in there, and the defaults are set to the way these names are used in Zipkin, which are different. In Dubbo, they happen to be the same, which does indeed lead to a little duplication, but I can't think of a better way of handling this scenario.

[codefromthecrypt]

ps I would make a milestone of this project: used by someone besides zipkin

would be cool to reach that, even if maybe now isn't the best time.