Re: [cross-project-issues-dev] Question about signing and pack200

[David M Williams <david_williams@xxxxxxxxxx>]

> I had understood "sign" would also pack. 
> By default, it is not done in our build and there is no pack.gz 
> after the signing.
> Should I do something more specific for pack?

The signing script does, sort of, run pack, before it
signs, but it is the "conditioning" part of pack, sometimes called
"repack". This makes sure a signed jar can later be packed in
the most efficient way and that once it is finally packed it can be unpacked
without invalidating the signature. In other words, it does stuff to the
jar that has to be done before its signed. To actually produce the *pack.gz
files is a separate step. you need to do later. Luckily there is a handy
ant task that will both produce the pack.gz files, and update the repository
metadata appropriately: p2.process.artifacts. I run the task with "antRunner"
from Eclipse, since it is a p2 task. Something like the following

<project
    default="processArtifacts"
    basedir=".">
    <target
        name="processArtifacts">

        <!-- repoDirLocation
normally set by caller, but can be set here locally if using stand alone
--> 
        <property
            name="repoDirLocation"
            value="/opt/public/webtools/committers/wtp-R3.3.0-S/20110127064115/S-3.3.0-20110127064115/repository"/>
        <p2.process.artifacts
            pack="true"
            repositoryPath="file:/${repoDirLocation}"/>

        <!-- clean up some
unnecessary files -->
        <delete
            failonerror="false">
            <fileset
               
dir="${repoDirLocation}"
               
includes="artifacts.jar.pack.gz, content.jar.pack.gz, site.xml"/>
        </delete>

    </target>
</project>
 
Part of the "logic" behind this process, is
its often best to always produce the signed jars in a repo, some of us
do that every build, and some of us produced an archive of the whole repo
at this point (so it has only metadata, and jars) and then, when producing
the final repo, that you know will be accessed via http, then run p2.process.artifacts,
with 'pack' attribute (a time consuming process), since the pack.gz files
are most useful to save bandwidth when downloading them with http. 

HTH






From:      
 Vincent Zurczak <vincent.zurczak@xxxxxxxxxxxxxx>
To:      
 cross-project-issues-dev@xxxxxxxxxxx
Date:      
 05/18/2011 01:44 AM
Subject:    
   [cross-project-issues-dev]
Question about signing and pack200
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

Hi,

I'm not sure if this mailing-list is the place to ask this question, but
I don't see a better one right now.
SCA Tools has a build on Hudson based on Tycho. What I would like to do
is to "promote" the last generated update site, meaning packing
and signing it (manually for the moment).

I logged in through SSH to build.eclipse.org and applied the "sign"
command on the update site.
Signing seems good but pack is not done. Instead, the logs include:

Running Repack Sign on /shared/download-staging.priv/stp/out/temp_site_assembly_2.2.0.20110517171311.zip/plugins/org.eclipse.soa.sca.sca1_0.model_2.2.0.201105171710.jar

I had understood "sign" would also pack. 
By default, it is not done in our build and there is no pack.gz after the
signing.

Should I do something more specific for pack?

Thanks for any help,

                    
                 Vincent.



PS: I also plan to script the signing thanks to this Maven plugin [0] as
soon as it is released.


[ 0 ] : https://bugs.eclipse.org/bugs/show_bug.cgi?id=342336

-- 
Vincent Zurczak 

R&D Engineer 
Petals
Link - SOA open-source company 
http://vzurczak.wordpress.com
+33 (0) 4 76 96 15 16_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev