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/10 15:54:49 UTC

svn commit: r1811733 - in /uima/site/trunk/uima-website: docs/dev-eclipse-plugin-signing.html xdocs/dev-eclipse-plugin-signing.xml

Author: schor
Date: Tue Oct 10 15:54:49 2017
New Revision: 1811733

URL: http://svn.apache.org/viewvc?rev=1811733&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=1811733&r1=1811732&r2=1811733&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 Tue Oct 10 15:54:49 2017
@@ -246,20 +246,45 @@ allows the plugin installer to avoid say
                                                 <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>
-                                                <p>After the vote passes, the prepare-to-sign ant build is run.  This rebuilds the update site, just like the
-        previous build, but stops at the point of doing the JAR processing for the new plugins, where before it ran
-        the Jarprocessor with the -repack and -pack options, now it runs with just the -repack options.  
-        This puts the packed/conditioned JARs into target/eus-work/plugins, named x.y.z_3.0.1.jar, for example.
-     </p>
-                                                <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/plugins, and signs them.  The signed Jars are down-loaded into 
+                                                <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 (not the *.pack.gz files), and signs them.  The signed Jars are down-loaded into 
        a new directory, target/eus-work-signed/plugins/. </p>
-                                                <p>Now the finish-after-signing ant build is run.  This task does all the remaining steps, including Apache GPG
-        signing of the artifacts.</p>
+                                                <p>Now the finish-after-signing ant build is run.  This task does all the remaining steps, starting with the -pack 
+        step, regenerating the *.pack.gz files in the eus-work-signed/plugins directory, 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>
                                                 <p>Please try installing the result to confirm nothing went wrong in this re-build process.</p>
                             </blockquote>
         </td></tr>
     </table>
+                                                      <table class="subsectionTable">
+        <tr><td>
+       
+       
+       
+          <a name="Changes to Normal Build">
+            <h2>Changes to Normal Build
+                        </h2>
+          </a>
+      </td></tr>
+      <tr><td>
+        <blockquote class="subsectionBody">
+                                    <p>To support signing, the normal build needs 2 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.
+        </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
+            to be redone, the original contents.jar and artifacts.jar files need to be saved so they can be restored
+            before the rebuild with signed artifacts.</li>
+      </ol>
+    </p>
+                            </blockquote>
+        </td></tr>
+    </table>
                             </blockquote>
         </p>
       </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=1811733&r1=1811732&r2=1811733&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 Tue Oct 10 15:54:49 2017
@@ -43,22 +43,33 @@ allows the plugin installer to avoid say
        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>
      
-     <p>After the vote passes, the prepare-to-sign ant build is run.  This rebuilds the update site, just like the
-        previous build, but stops at the point of doing the JAR processing for the new plugins, where before it ran
-        the Jarprocessor with the -repack and -pack options, now it runs with just the -repack options.  
-        This puts the packed/conditioned JARs into target/eus-work/plugins, named x.y.z_3.0.1.jar, for example.
-     </p>
-     
-     <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/plugins, and signs them.  The signed Jars are down-loaded into 
+     <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 (not the *.pack.gz files), and signs them.  The signed Jars are down-loaded into 
        a new directory, target/eus-work-signed/plugins/. </p>
        
-     <p>Now the finish-after-signing ant build is run.  This task does all the remaining steps, including Apache GPG
-        signing of the artifacts.</p>
+     <p>Now the finish-after-signing ant build is run.  This task does all the remaining steps, starting with the -pack 
+        step, regenerating the *.pack.gz files in the eus-work-signed/plugins directory, 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>
         
      <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.
+      <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.
+        </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
+            to be redone, the original contents.jar and artifacts.jar files need to be saved so they can be restored
+            before the rebuild with signed artifacts.</li>
+      </ol>
+    </p>
+  </subsection>
 </section>
 
 <section name="Release Manager needs to have a valid code signing certificate">