Amazon S3 plugin for Jenkins CI again

About once a year I revisit (link) this topic again (usually when the plugin causes trouble). Now I get this signature error

AWS Error Code: SignatureDoesNotMatch, AWS Error Message: The request signature we calculated does not match the signature you provided. Check your key and signing method., S3 Extended Request ID:..

The good news first:
The S3 plugin became mainstream, you can install it from the plugin page under Jenkins Administration | Plugin Manager. You dont need to build the plugin any longer by yourself and can skip the rest of this entry.

S3 Plugin

The long version:
It seems the error is caused by a ‘+’ sign in the access key troubling the encoding function used (see issue). The latest build (Sep 2012) should fix this problem.

If you want to build by yourself, you need to get the sourcecode from git and build the plugin file, beware as it requires Maven 3 now. Below instructions apply fro Ubuntu.

Upload plugin



Amazon S3 plugin for Jenkins CI

About one year back I found this plugin, that saves your build artifacts to Amazon S3 storage. Unfortunately the plugin does not properly work with the current Jenkins versions and the original plugin is not maintained. Luckily someone forked and updated the plugin at github. You need to build the plugin by yourself with the help of maven, you still can refer to my original post, just one change is required to make it work, the settings for your ~/.m2/settings/xml need to be changed according to the plugin page description. Please be patient, maven is going to download a lot !


 <!-- Give access to Jenkins plugins -->
 <activeByDefault>true</activeByDefault> <!-- change this to false, if you don't like to have it on per default -->

Otherwise you get errors like

[INFO] Scanning for projects...
[INFO] Unable to find resource 'org.jenkins-ci.plugins:plugin:pom:1.434' in repository java.net2 (
[INFO] Unable to find resource 'org.jenkins-ci.plugins:plugin:pom:1.434' in repository central (
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Automatic Version Numbering in Web Applications with Hudson (Add-On)

In the 3 parts of the tutorial (part 1, part 2, part3) we setup a Netbeans/Web-Project/Hudson/ZK environment that creates and reads automatically version numbers. Unfortunately while building outside HUDSON, or better with your local Netbeans IDE, ANT can’t read the HUDSON variables, resulting in a Manifest like this:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 14.2-b01 (Sun Microsystems Inc.)
builduser: sven
version: ${env.BUILD_VERSION}
id: ${env.BUILD_ID}
tag: ${env.BUILD_TAG}
server: ${env.BUILD_URL}

And potentially the website will display ${env.BUILD_VERSION} as version. Not very professional. Of course a local build should not find its way to production system, but at least it should state it properly.

Continue reading

Automatic Version Numbering in Web Applications with Hudson (Part 3)

In this third and last part of the tutorial (part 1, part 2) we add the version reading feature to a ZK application, which is actually not a big difference to the regular jsp page that we created earlier.
It is also a good exercise how to add the ZK library to an existing web project.


  • Netbeans 6.8
  • Glassfish V3 Application Server
  • Installed ZK 5.0 Plugin for Netbeans (link)

(Older Versions and non-EE6 work as well)

Continue reading

Automatic Version Numbering in Web Applications with Hudson (Part 2)

Lets continue with the application from part 1(link) wit a static MANIFEST.MF file to dynamically created attributes using the ANT manifest task.

Requirements for this tutorial

  • Netbeans 6.8
  • Glassfish V3
  • Hudson (local running good enough, how-to’s on Hudson setup you find in my earlier Tutorials)

Tutorial Part 2

Automatic Version Numbering in Web Applications with Hudson (Part 1)

Creating a web application deployed to a multitude of servers (or even to 1 server only) will put you to the challenge to find out what are you actually looking at when opening its URL. At good old windows time you could “compile” a major/minor version string into the executable and at least check the exe-files properties. There is no equivalent if you open a website. You could choose to put a version manually at your page (the least advanced and error prone way) or you make your automatic build (CI) server (that also might deploy to test systems) to write a time and version stamp into a property file (which happens to be the MANIFEST.MF file which usually gets little to no attention) and make the web application self-aware of its version number and print it somewhere on the index page.
I came across a couple of online discussions with solutions using the InputStreamReader, but it didnt worked for me. Either it reads null or the manifest file of some other jar files in the classpath.

This tutorial cover 3 parts:

  1. Create a web application that reads from the manifest file.
  2. Extend the ant script and make Hudson adding the build number and ID into the war file.
  3. Create a ZK application that reads from the manifest file.

Information on the manifest file

  • The MANIFEST.MF is a file inside the META-INF directory which is optional. The Netbeans IDE creates it. Actuall ant is creating it. Guess it became de-facto standard without many people really looking at this file(s).
    By default it contains usually only one line “Manifest-Version: 1.0”
    References: link1, link2
  • Infos on the ANT manifest task (link)

Requirements for this tutorial

  • Netbeans 6.8
  • Glassfish V3

    (earlier might work as well, but I did not test it)

Continue reading