Building samigo-audio module from source creates an unsigned jar
GENERAL
TESTING
GENERAL
TESTING
Description
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 SAM-1783.
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:
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/ cd samigo-2.8.5/ mvn clean install find . -name samigo-audio-2.8.5.jar (./samigo-audio/target/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:
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.
What is the test plan for this? Is this ready for merging or is more work needed?
Matthew Jones November 19, 2012 at 11:56 AM
I agree with this, I would use released versions instead of the snapshots though.
2.8 should use the a latest release released 2.8. In I just made the version 2.8.2. I update this and added a new variable. This should be merged, and I think 2.9 should use the released 2.9.0 because it did change slightly in 2.9 to support IE9.
Steve Swinsburg October 30, 2012 at 6:20 PM
r115327
Added profile wrapper around the samigo-audio module. It is the same profile id that is activated at release time so there is no change. The only issue might be if there is no snapshot version of the artifact released into the repo when someone builds a snapshot of the code. We can resolve that by releasing snapshots but I believe that is already handled by Mr Jenkins.
Lydia Li October 8, 2012 at 2:26 PM
Steve, we are okay with your proposed solution. Can you make the changes so the building of this module is conditional on the release process?
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 SAM-1783.
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:
in samigo-aduio/pom.xml:
<id>jarsign</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
and
<configuration>
<keystore>${sakai.samigo-audio.jarsign.keystore.location}</keystore>
<alias>${sakai.samigo-audio.jarsign.alias}</alias>
<storepass>${sakai.samigo-audio.jarsign.password}</storepass>
<verify>true</verify>
</configuration>
I had the same issue when doing the 2.8.2 release, and had to build Samigo in a special way:
https://confluence.sakaiproject.org/display/~steve.swinsburg/sakai-2.8.2+release
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/
cd samigo-2.8.5/
mvn clean install
find . -name samigo-audio-2.8.5.jar
(./samigo-audio/target/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
./samigo-audio/2.8.5/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
jar verified.
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.
Also resolves SAM-1783.