The samigo-audio module is built whenever someone builds from source, however this creates an unsigned jar. This causes problem, such as those reported in
The artifact that this module creates is in the maven repo and is signed correctly, so the solution is to just remove it from the normal build.
However it still needs to be built for releases so I propose wrapping that module in a profile which is activated only at release time.
Copy of analysis below:
Basically, the build for the release DOES get signed as part of the release process, but the profile doesn't get activated when people build it from source, AND the properties are missing that actually do the signing:
I had the same issue when doing the 2.8.2 release, and had to build Samigo in a special way:
mvn2 release:clean release:prepare release:perform -P jarsign -Dsakai.samigo-audio.jarsign.keystore.location=/path/to/sakai.keystore -Dsakai.samigo-audio.jarsign.alias=ALIAS -Dsakai.samigo-audio.jarsign.password=PASSWORD
but that obviously doesn't happen when you just do a mvn clean install sakai:deploy so one would assume that the jar isn't being signed.
I verified this by checking out samigo 2.8.5 and building like anyone else would:
svn co https://source.sakaiproject.org/svn//sam/tags/samigo-2.8.5/
mvn clean install
find . -name samigo-audio-2.8.5.jar
jarsigner -verify ./samigo-audio/target/samigo-audio-2.8.5.jar
jar is unsigned. (signatures missing or not parsable)
So, one would think that we don't build the samigo-audio module and have the build always pull the signed one from the repository?
As a followup, I cleaned out my local repo, removed the samigo-audio module from the samigo pom so that it would force a download of the jar from the remote repo (where it IS signed), build and verified:
[imac:~/.m2/repository/org/sakaiproject/samigo]$ find . -name samigo-audio-2.8.5.jar
[imac:~/.m2/repository/org/sakaiproject/samigo]$ jarsigner -verify ./samigo-audio/2.8.5/samigo-audio-2.8.5.jar
So I'm thinking that we make the building of this module conditional on the release process, i.e. normal source deploys don't build it.
Ok I've confirmed that removing this module from the build makes things behave correctly. It gets the correct signed jar from the remote repo and everything is happy with recording.