The version of commons-cli (1.0) that ships with SL5 breaks our option parsing mechanism.
So we embed commons-cli 1.2 in our dependency dir. I've changed the packaging script to fix the classloading
and now it works on SL5. On SL6 I thought that bouncycastle-mail was in EPEL, but I cannot find it in my
local SL6 machine, so I guess I will need the package also for that platform.
This can be set to done.
The repo is now in italiangrid.

Added the conflicts.

The current spec file does not specify a conflict with the old voms-clients package, while it should.

All you need to do is download the repo file and put it in /etc/yum.repos.d.

BTW, I've forked voms-clients and fixed some stuff so that now the deployment works.
You can test stuff using this yum repo:

http://radiohead.cnaf.infn.it:9999/job/yumrepo_voms_clients_3_0_SL5/

The jar loading approach as implemented in the scripts needs to be changed.
When installing from RPMS it includes in the CLI all the jars installed in /usr/share/java.
I think we should rethink this, and let the rpm postinstall script create a classpath variable
that is leveraged by the scripts.

First commit https://github.com/valerioventuri/voms-clients-rpm.

I still need to understand how the setting.xml get to the build machine and how I am supposed to know where it is.

I have not tested it with mock.

Done the same for voms-api-java https://github.com/valerioventuri/voms-api-java-rpm.

Prepared Makefile and spec file following voms-api-java's. Need to make clear which is the authoritative font for the version. Still need to add all the requires for the deps.

This is indeed a voms-api-java packaging issue.

We have to decide whether taking bcmail in our belly or providing an RPM in the third-party EMI repo. I have created the RPM for bcmail so we have a real choice.

http://radiohead.cnaf.infn.it:9999/job/bcmail146-SL5/

5h