How to verify Apache Apex release candidate builds
Download the KEYS file and import it. Verify that the key just imported is correct.
gpg --import KEYS
gpg --fingerprint <key-id>
The <key-id> of the release manager can be found out in the PGP key link in the mail. It would be alphanumric number like D920A98Cbb. The above step can be skipped if you have already imported key of the current release manager.
More about key verification at http://www.apache.org/info/verification.html
You can also create your own key which is required if you would like to sign the build. This step is optional.
Please provide 4096 as keysize while generating the key.
File integrity check
Download all files present in staging directory of the RC build. Staging directory link is shared in VOTE thread of the release candidate. It is recommended that these files are downloaded in a clean directory.
wget -r -np -nd <staging-area-link>/
Note the link should end with "/".
Define the apex release candidate variable. We will use apache-apex-core-3.6.0 as an example.
Verify integrity of tar.gz file:
gpg --verify $APEX_RELEASE_CANDIDATE-source-release.tar.gz.asc
md5sum --check $APEX_RELEASE_CANDIDATE-source-release.tar.gz.md5
shasum -a 512 --check $APEX_RELEASE_CANDIDATE-source-release.tar.gz.sha512
Verify integrity of .zip file:
gpg --verify $APEX_RELEASE_CANDIDATE-source-release.zip.asc
md5sum --check $APEX_RELEASE_CANDIDATE-source-release.zip.md5
shasum -a 512 --check $APEX_RELEASE_CANDIDATE-source-release.zip.sha512
Source code verification
You can extract source either using .tar.gz file or .zip file.
Using .tar.gz source
Extract source using .tar.gz:
tar -zxvf $APEX_RELEASE_CANDIDATE-source-release.tar.gz
Using .zip source
Any of the two commands above will create a directory named after apex release candidate.
Miscellaneous checks: Part I (Pre Compilation)
Existence of LICENSE, NOTICE, README.md and CHANGELOG.md files.
Please make sure these files are present in the parent folder after extracting the zip or tar. The CHANGELOG.md file should contain change log for the current release.
No unexpected binary files in the sources.
The extracted directory should not contain any binary. Need to test this before compiling the source code.
find . -type f -name '*.*' | sed 's|.*\.||' | sort -u
Please make sure no binary extension is listed here. Likely candidates are .jar files. Additionally, for Malhar, demo package files, i.e. .apa files.
For Apex Core:
mvn clean apache-rat:check verify -Dlicense.skip=false install
For Apex Malhar:
mvn clean apache-rat:check verify -Dlicense.skip=false -Pall-modules install
Jars should be installed in your maven repository, typically in ~/.m2/repository/org/apache/apex/ directory
Following step is optional and needs the key generated by you as in prerequisite section given above.
mvn verify -Papache-release -DskipTests
For verification of Apex build, check backward compatibility with respect to Malhar. Locally update apex.core.version in Malhar to point to to-be released version of apex-core and recompile Malhar.
Launch a few demos to make sure everything is working fine using apex utility. The apex script is present at /engine/src/main/scripts/apex . If apex-core is being verified, then simply use engine/src/main/scripts/apex to launch the script. Otherwise, prefix it with apex-core folder path.
You will get apex prompt, where demos can be launched.
apex> launch <demo-apa-file>
Demo apa files are typically in apex-malhar/demos directory.
Miscellaneous checks: Part II (Post compilation)
Correct artifact names:
All the apex artifacts generated in local maven build directory should contain classs jar, sources jars, javadocs jar. All the artifacts are under ~/.m2/repository/org/apache/apex/ directory on your local machine.