Case:
Dictionaries where missing from client installation on Windows machines.
Client is multi user and users are not allowed to write in Program Directories (non admin on their PCs).
Client is IBM Notes 9.0.1FP6, because this is the one rolled out to end users.
This means that nothing can be installed via Widgets in framework\rpc or framework\shared because both are under Program Directory.
Objective is to provide all of the dictionaries to the end users to choose from from the Widgets catalog. Installation should progress without any questions asked.

Description:
I downloaded the Dictionaries provided by IBM (Notes_XTAF_Dictionaries_V9.0_Win_ML.zip).
For a full description of this package, please read Tomas Hampels blog at
(https://blog.thomashampel.com/blog/tomcat2000.nsf/dx/deploying-xtaf-dictionaries-as-widgets.htm

The problem I got was that the Feature jar files configured to install in framework\rpc which is fine if you include them during installation of the original package running with administrative rights on the computer.

Only way in my scenario was to make sure that the installation was made in a user context meaning Data\workspace\applications

Solution:
Change configuration of the Feature jar to make sure that the installation is done in a user context.

Unpacking the jar file in the features directory of any given dictionary reveals that the feature.xml file contains <feature colocation-affinity="com.ibm.rcp.platform.feature"
this needs to be changed to this <feature colocation-affinity="com.ibm.rcp.site.anchor.user.feature" to make sure that installation will go to Data\workspace\applications where the end user is allowed to write.

To unpack and repack i use PeaZip (https://www.peazip.org/peazip-64bit.html and as an Editor I use Notepad++ (https://notepad-plus-plus.org/download/v7.3.3.html

Explanation of the different options could be found here:
https://www.ibm.com/support/knowledgecenter/en//SSVHEW_6.2.0/com.ibm.rcp.tools.doc.admin/controllingfeatureinstallocation.html
https://www-01.ibm.com/support/docview.wss?uid=swg21497657
https://www-01.ibm.com/support/docview.wss?uid=swg21440976

Also when doing this it will break the signatures and this means that a resigning (after repackage) is necessary for security reasons (you should not allow anything that you have not trusted)
If you want to include your own signed jars files during installation of the client, this can be done following this instruction (https://www-01.ibm.com/support/docview.wss?uid=swg21305165)
You could also use iKeyman to do this if you prefer.

If you look at Tomas Hampels blog above you will find that there are a lot of files that needs to be changed and signed before importing to an update site.

Changing:
In every features directory in every updateSite_xx directory the file feature.xml needs to be changed according to the above solution.
IMPORTANT!!!
Also, preparing for signing, 3 files need to be deleted from a subdirectory called META-INF also in the features catalog:
IBM_WPLC.RSA
IBM_WPLC.SF
MANIFEST.MF
IMPORTANT!!!

Preparing:
Repack all files in each Directory e.g. com.ibm.langware.v5.dic.af_ZA.feature_7.2.0.201111100545 to com.ibm.langware.v5.dic.af_ZA.feature_7.2.0.201111100545.zip
Move (cut) the zip file to where the original jar file is located rename the original jar file with an extension .org instead of .jar end the rename the newly moved .zip file to .jar
A features catalog could then look like this:

Signing:
To sign I downloaded JDK 1.8 from
(https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html Windows x64 because I am using W10 64-bit.

IMPORTANT!!!
Only sign jar files that you have made changes to. The others are already signed with valid signatures.
Only sign 1 time with 1 signature for each jar file. Signing a second time could cause unexpected results.
IMPORTANT!!!

First I examined the file that was signed by IBM, this is now <filename>.org if the instructions where followed.
C:\Program Files\Java\jdk1.8.0_121\bin>
jarsigner -verify -verbose "C:\updateSite_af\features\com.ibm.langware.v5.dic.af_ZA.feature_7.2.0.201111100545.org"

I got:
– Signed by "CN=International Business Machines Corporation, OU=Lotus Software Group, OU=Digital ID Class 3 – Java Object Signing, O=International Business Machines Corporation, L=Littleton, ST=Massachusetts, C=US"
    Digest algorithm: SHA1
    Signature algorithm: MD5withRSA, 2048-bit key
  Timestamped by "CN=GeoTrust Timestamping Signer 1, O=GeoTrust Inc, C=US" on lö feb 02 04:31:44 UTC 2013
    Timestamp digest algorithm: SHA-1
    Timestamp signature algorithm: SHA1withRSA, 1024-bit key

jar verified.

This meant that I need to sign with MD5withRSA and also SHA-1 where needed.
I tried all of the possible combinations of signing and digest and did the provisioning to the IBM Notes Client for all the different cases (puh this was hard and took a lot of time!) just to make sure.
I found only 1 configuration that worked all of the times.

IMPORTANT!!!
To sign you must first create a signer and also you need to import the certificate of the signer and crosscertify it with your Notescertificate and push that crosscertificate to the client thru your security policy.
This done is done in your Domino Directory of the server.
Signing the jar file with this signature is then trusted to be installed on the client.
IMPORTANT!!!

Inspired by Tomas Hampel (again) and the blog entry (https://blog.thomashampel.com/blog/tomcat2000.nsf/dx/untitled.htm?opendocument&comments).
I decided to make my own script to help me out with this task.

Script Solution:
I decided to make 2 types of script, 1 for creating the necessary JKS file used for signing and 1 for the actual signing.
Both solutions consists of a command file an a property file containing values needed for the execution.

Code and samples will be provided here for download.Cool_Signing

Keytool:
Signing_mykeytool.cmd Cool_Signer.keytool
in the sample provided and this will create a JKS file and a CER file in the C:\temp directory.

To customize for your own needs you can creating you own .keytool file using Cool_Signer.keytool as a template. Read the included Readme.txt file for explanation.

IMPORTANT!!!
You must change/customize this if You want to use this in your own environment, because sample provided here is not intended for other purposes than demonstrating the code.
IMPORTANT!!!

Jarsigner:
Signing_myjarsigner.cmd Cool_Signing_with_XTAF_MD5.jarsigner
in the sample provided will sign all jar files that ends with *.feature_7.2.0.201111100545.jar from the catalog C:\Notes_XTAF_Dictionaries_V9.0_Win_ML and down.
IMPORTANT!!!
It also contains the parameters that where tested to work with these features. I will recommend you to use these if you modify and sign the XTAF Dictionaries.
IMPORTANT!!!

To customize for your own needs you can creating you own .jarsigner file using Cool_Signing_with_XTAF_MD5.jarsigner as a template. Read the included Readme.txt file for explanation.

Conclusion:
Changing and Signing is hard work but script at least provides you with the means of organising your stuff and ease the burden of signing.