You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@uima.apache.org by sc...@apache.org on 2019/04/10 20:12:11 UTC
svn commit: r1857279 - in /uima/site/trunk/uima-website:
docs/dev-eclipse-plugin-signing.html xdocs/dev-eclipse-plugin-signing.xml
Author: schor
Date: Wed Apr 10 20:12:10 2019
New Revision: 1857279
URL: http://svn.apache.org/viewvc?rev=1857279&view=rev
Log:
no jira - clarify / improve eclipse plugin signing
Modified:
uima/site/trunk/uima-website/docs/dev-eclipse-plugin-signing.html
uima/site/trunk/uima-website/xdocs/dev-eclipse-plugin-signing.xml
Modified: uima/site/trunk/uima-website/docs/dev-eclipse-plugin-signing.html
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/docs/dev-eclipse-plugin-signing.html?rev=1857279&r1=1857278&r2=1857279&view=diff
==============================================================================
--- uima/site/trunk/uima-website/docs/dev-eclipse-plugin-signing.html (original)
+++ uima/site/trunk/uima-website/docs/dev-eclipse-plugin-signing.html Wed Apr 10 20:12:10 2019
@@ -235,10 +235,9 @@ allows the Eclipse installer to avoid sa
</p>
<p>
It also enables automatic notification and subsequent update (if the user chooses) of upgrades. Because of this,
-insure your feature id's are different for versions which should not automatically update. For instance,
-the uimav3 vs the v2 - looks
+insure your feature id's are different for versions which should not automatically update.
</p>
- <p>Both the feature jars and the plugin jars need to be signed.</p>
+ <p>Both the feature jars and the plugin jars need to be signed. But not the pack.gz things or the artifacts / contents jars.</p>
<table class="subsectionTable">
<tr><td>
@@ -259,14 +258,22 @@ the uimav3 vs the v2 - looks
new Jars, and writes the "tag" for this into SVN for record keeping.</p>
<p>After the vote passes
the release manager, using their special credentials, logs onto the signing portal. This process
- requires a one-time code, which the portal will send to you. (Note: I had to refresh my web browser in order to
- get the screen showing that option). Once signed, in, make a signing set
+ requires a one-time code, which the portal will send to you.</p>
+ <p style="margin-left: 40px">(Note: I had to refresh my web browser in order to
+ get the screen showing that option).
+ </p>
+ <p>Once signed, in, make a signing set
consisting of all of the Jars in target/eus-work/plugins and feature jars (feature jars must also be signed)
- (not the *.pack.gz files, nor the ..content nor ..artifact metadata Jars). Test sign these and download them.
- </p>
- <p>For safety, the build process makes a copy of the target/eus-work/plugins directory.
- Update the .jar files in that directory
- with the signed ones, overlaying the unsigned ones.</p>
+ (not the *.pack.gz files, nor the ..content nor ..artifact metadata Jars).
+ </p>
+ <p>For convenience, and to rename any name-collisions between jars in the features/ and plugins/ directories,
+ make a new folder (signingSet), and copy all the files from target/saved into that, renaming any
+ collisions.
+ </p>
+ <p>On the signing web application make a new signing set and upload these files to that set.
+ Then sign them (either use Test signing or Production signing). Test signing is only if you're new to
+ the whole process and want to test things work. Then download the result, and copy them into the
+ target/eus-work/features and /plugins directories, overlaying the unsigned ones.</p>
<p>Then rebuild the update site by running <code>mvn antrun:run@make-subsite-after-signing</code>.
This does the remaining steps,
including packing (regenerating the .pack.gz files in the /plugins) and adding the various
@@ -274,7 +281,8 @@ the uimav3 vs the v2 - looks
</p>
<p>Messages about "Artifact repository out of sync. Overwriting xxxx" are to be expected.</p>
<p>Please try installing the result to confirm nothing went wrong in this re-build process.</p>
- <p>If all is well, repeat the above process starting with selection "production" signing for the jars, downloading
+ <p>If you used a test signing, instead of a production signing,
+ if all is well, repeat the above process starting with selection "production" signing for the jars, downloading
those jars, replacing them into the eus-work directory, and re-running the mvn antrun:run@make-subsite-after-signing.</p>
</blockquote>
</td></tr>
@@ -353,18 +361,6 @@ the uimav3 vs the v2 - looks
</blockquote>
</p>
</td></tr>
- </table>
- <div class="sectionTable">
- <table class="sectionTable">
- <tr><td>
- <a name="Release Flow"><h1><img src="images/UIMA_4sq50tightCropSolid.png"/> Release Flow</h1></a>
- </td></tr>
- <tr><td>
- <blockquote class="sectionBody">
- <p>To be done...</p>
- </blockquote>
- </p>
- </td></tr>
</table>
</td>
</tr>
Modified: uima/site/trunk/uima-website/xdocs/dev-eclipse-plugin-signing.xml
URL: http://svn.apache.org/viewvc/uima/site/trunk/uima-website/xdocs/dev-eclipse-plugin-signing.xml?rev=1857279&r1=1857278&r2=1857279&view=diff
==============================================================================
--- uima/site/trunk/uima-website/xdocs/dev-eclipse-plugin-signing.xml (original)
+++ uima/site/trunk/uima-website/xdocs/dev-eclipse-plugin-signing.xml Wed Apr 10 20:12:10 2019
@@ -34,11 +34,10 @@ allows the Eclipse installer to avoid sa
<p>
It also enables automatic notification and subsequent update (if the user chooses) of upgrades. Because of this,
-insure your feature id's are different for versions which should not automatically update. For instance,
-the uimav3 vs the v2 - looks
+insure your feature id's are different for versions which should not automatically update.
</p>
-<p>Both the feature jars and the plugin jars need to be signed.</p>
+<p>Both the feature jars and the plugin jars need to be signed. But not the pack.gz things or the artifacts / contents jars.</p>
<subsection name="Process Flow">
<p>We use a 2 step process, to reduce costs to Apache for signing release candidates which subsequently fail.
@@ -51,16 +50,27 @@ the uimav3 vs the v2 - looks
<p>After the vote passes
the release manager, using their special credentials, logs onto the signing portal. This process
- requires a one-time code, which the portal will send to you. (Note: I had to refresh my web browser in order to
- get the screen showing that option). Once signed, in, make a signing set
+ requires a one-time code, which the portal will send to you.</p>
+
+ <p style="margin-left: 40px">(Note: I had to refresh my web browser in order to
+ get the screen showing that option).
+ </p>
+
+ <p>Once signed, in, make a signing set
consisting of all of the Jars in target/eus-work/plugins and feature jars (feature jars must also be signed)
- (not the *.pack.gz files, nor the ..content nor ..artifact metadata Jars). Test sign these and download them.
- </p>
+ (not the *.pack.gz files, nor the ..content nor ..artifact metadata Jars).
+ </p>
+
+ <p>For convenience, and to rename any name-collisions between jars in the features/ and plugins/ directories,
+ make a new folder (signingSet), and copy all the files from target/saved into that, renaming any
+ collisions.
+ </p>
+
+ <p>On the signing web application make a new signing set and upload these files to that set.
+ Then sign them (either use Test signing or Production signing). Test signing is only if you're new to
+ the whole process and want to test things work. Then download the result, and copy them into the
+ target/eus-work/features and /plugins directories, overlaying the unsigned ones.</p>
- <p>For safety, the build process makes a copy of the target/eus-work/plugins directory.
- Update the .jar files in that directory
- with the signed ones, overlaying the unsigned ones.</p>
-
<p>Then rebuild the update site by running <code>mvn antrun:run@make-subsite-after-signing</code>.
This does the remaining steps,
including packing (regenerating the .pack.gz files in the /plugins) and adding the various
@@ -71,7 +81,8 @@ the uimav3 vs the v2 - looks
<p>Please try installing the result to confirm nothing went wrong in this re-build process.</p>
- <p>If all is well, repeat the above process starting with selection "production" signing for the jars, downloading
+ <p>If you used a test signing, instead of a production signing,
+ if all is well, repeat the above process starting with selection "production" signing for the jars, downloading
those jars, replacing them into the eus-work directory, and re-running the mvn antrun:run@make-subsite-after-signing.</p>
</subsection>
@@ -111,10 +122,5 @@ the uimav3 vs the v2 - looks
https://wiki.eclipse.org/JAR_Signing#What_gets_signed</a> for background on signing Eclipse Plugins.</p>
</section>
-<section name="Release Flow">
-<p>To be done...</p>
-</section>
-
-
</body>
</document>