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 2017/10/11 12:45:50 UTC
svn commit: r1811821 - in /uima/site/trunk/uima-website:
docs/dev-eclipse-plugin-signing.html xdocs/dev-eclipse-plugin-signing.xml
Author: schor
Date: Wed Oct 11 12:45:50 2017
New Revision: 1811821
URL: http://svn.apache.org/viewvc?rev=1811821&view=rev
Log:
[UIMA-5583] improve method for 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=1811821&r1=1811820&r2=1811821&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 Oct 11 12:45:50 2017
@@ -223,11 +223,11 @@
</td></tr>
<tr><td>
<blockquote class="sectionBody">
- <p>All released Apache artifacts are normally signed. Eclipse plugin jar signing is in addition
+ <p>All released Apache artifacts are normally signed. Eclipse jar signing is in addition
to the Apache release signing. This additional signing (with a recognized authority certificate)
-allows the plugin installer to avoid saying it is installing unsigned artifacts, and needs permission to continue.
+allows the plugin installer to avoid saying it is installing unsigned artifacts and needs permission to continue.
</p>
- <p>Both the feature jars and the plugin jars are signed.</p>
+ <p>Both the feature jars and the plugin jars are signed. Feature Jars might not need signing - but it doesn't hurt.</p>
<table class="subsectionTable">
<tr><td>
@@ -242,18 +242,19 @@ allows the plugin installer to avoid say
<blockquote class="subsectionBody">
<p>We use a 2 step process, to reduce costs to Apache for signing release candidates which subsequently fail.
After the release vote passes, feature and plugin Jar files (but not the pack.gz files) are manually uploaded and signed,
- and then a subsequent maven task is run to rebuild just the site packaging artifacts.</p>
+ and then a subsequent maven task is run to rebuild just the site packaging artifacts using the signed Jars.</p>
<p>The first step is to do a normal build of the update site, using mvn release:prepare.
- This produces the artifacts for voting on, without signing the
- new plugin Jars, and writes the "tag" for this into SVN for record keeping.</p>
+ This produces the artifacts for voting on, without jar-signing the
+ 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, and makes a signing set
- consisting of all of the Jars in target/eus-work/plugins and .../features (not the *.pack.gz files), and signs them.
- The signed Jars are down-loaded into the same directory.</p>
- <p>Rebuild the site artifacts by running <code>mvn antrun:run</code>. This does the remaining steps,
+ the release manager, using their special credentials, logs onto the signing portal, and makes a signing set
+ consisting of all of the Jars in target/eus-work (not the *.pack.gz files), and signs them.
+ The signed Jars are down-loaded and unzipped, and replaced into the same directories.</p>
+ <p>The update site is rebuilt using the signed Jars by running <code>mvn antrun:run</code>.
+ This does the remaining steps,
including packing (regenerating the .pack.gz files in the /plugins) and adding the various
- signatures and checksums to these. These are then re-merged with any previous contents of the update site,
- and re-published.</p>
+ signatures and checksums to these. These are then re-published, merging with any previous contents of the update site.
+ </p>
<p>Please try installing the result to confirm nothing went wrong in this re-build process.</p>
</blockquote>
</td></tr>
@@ -270,11 +271,11 @@ allows the plugin installer to avoid say
</td></tr>
<tr><td>
<blockquote class="subsectionBody">
- <p>To support signing, the normal build needs 2 small changes.
+ <p>To support signing, the normal build needs some small changes.
<ol>
<li>(actually a bug fix) The existing build after running the JarProcessor, copies the original (unprocessed) Jars
- into the eus-work/plugins - accidentally overwriting the repacked/conditioned Jars. This step should be deleted;
- it is unnecessary.
+ into the eus-work/plugins - accidentally overwriting the repacked/conditioned Jars. This step must be deleted;
+ in order to have the processed/conditioned Jars available for signing.
</li>
<li>When doing the subsite build, any previous versions are combined with the new version. This is done by
downloading the previous versions into a new instance of the subsite. Because this packaging step needs
@@ -282,6 +283,8 @@ allows the plugin installer to avoid say
before the rebuild with signed artifacts.</li>
</ol>
</p>
+ <p>Additionally, to aid in reproducing things, the pre-signed, conditioned JARs are saved; in case of need, they can
+ be restored without rebuilding them again. This step might be removed in the future - it is not essential.</p>
</blockquote>
</td></tr>
</table>
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=1811821&r1=1811820&r2=1811821&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 Oct 11 12:45:50 2017
@@ -27,41 +27,42 @@ under the License.
<body>
<section name="Overview">
-<p>All released Apache artifacts are normally signed. Eclipse plugin jar signing is in addition
+<p>All released Apache artifacts are normally signed. Eclipse jar signing is in addition
to the Apache release signing. This additional signing (with a recognized authority certificate)
-allows the plugin installer to avoid saying it is installing unsigned artifacts, and needs permission to continue.
+allows the plugin installer to avoid saying it is installing unsigned artifacts and needs permission to continue.
</p>
-<p>Both the feature jars and the plugin jars are signed.</p>
+<p>Both the feature jars and the plugin jars are signed. Feature Jars might not need signing - but it doesn't hurt.</p>
<subsection name="Process Flow">
<p>We use a 2 step process, to reduce costs to Apache for signing release candidates which subsequently fail.
After the release vote passes, feature and plugin Jar files (but not the pack.gz files) are manually uploaded and signed,
- and then a subsequent maven task is run to rebuild just the site packaging artifacts.</p>
+ and then a subsequent maven task is run to rebuild just the site packaging artifacts using the signed Jars.</p>
<p>The first step is to do a normal build of the update site, using mvn release:prepare.
- This produces the artifacts for voting on, without signing the
- new plugin Jars, and writes the "tag" for this into SVN for record keeping.</p>
+ This produces the artifacts for voting on, without jar-signing the
+ 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, and makes a signing set
- consisting of all of the Jars in target/eus-work/plugins and .../features (not the *.pack.gz files), and signs them.
- The signed Jars are down-loaded into the same directory.</p>
+ the release manager, using their special credentials, logs onto the signing portal, and makes a signing set
+ consisting of all of the Jars in target/eus-work (not the *.pack.gz files), and signs them.
+ The signed Jars are down-loaded and unzipped, and replaced into the same directories.</p>
- <p>Rebuild the site artifacts by running <code>mvn antrun:run</code>. This does the remaining steps,
+ <p>The update site is rebuilt using the signed Jars by running <code>mvn antrun:run</code>.
+ This does the remaining steps,
including packing (regenerating the .pack.gz files in the /plugins) and adding the various
- signatures and checksums to these. These are then re-merged with any previous contents of the update site,
- and re-published.</p>
+ signatures and checksums to these. These are then re-published, merging with any previous contents of the update site.
+ </p>
<p>Please try installing the result to confirm nothing went wrong in this re-build process.</p>
</subsection>
<subsection name="Changes to Normal Build">
- <p>To support signing, the normal build needs 2 small changes.
+ <p>To support signing, the normal build needs some small changes.
<ol>
<li>(actually a bug fix) The existing build after running the JarProcessor, copies the original (unprocessed) Jars
- into the eus-work/plugins - accidentally overwriting the repacked/conditioned Jars. This step should be deleted;
- it is unnecessary.
+ into the eus-work/plugins - accidentally overwriting the repacked/conditioned Jars. This step must be deleted;
+ in order to have the processed/conditioned Jars available for signing.
</li>
<li>When doing the subsite build, any previous versions are combined with the new version. This is done by
downloading the previous versions into a new instance of the subsite. Because this packaging step needs
@@ -69,6 +70,8 @@ allows the plugin installer to avoid say
before the rebuild with signed artifacts.</li>
</ol>
</p>
+ <p>Additionally, to aid in reproducing things, the pre-signed, conditioned JARs are saved; in case of need, they can
+ be restored without rebuilding them again. This step might be removed in the future - it is not essential.</p>
</subsection>
</section>