Re: when to do the signing:
My understanding which might be incorrect is that the Jar "signature" is
compared against on computed when the jar is downloaded.
I suspect this compare will fail if you compute this **before** "Compress plugin
Jars....", because the signature will be computed on the un-packed Jar, but will
be verified using the packed Jar.
Of course, this is something to test :-). Since both packed and unpacked
versions are part of the Eclipse update site (the packed ones are tried first,
unless there's some older version of Eclipse (before packing) trying to use the
update site), we might need to sign both versions.
------------------------------------------
Re: signing features - these are tiny jars, and therefore not packed; Eclipse
might required them to be unpacked; so it's probably not a good idea to copy
these to ${toBePacked}.
------------------------------------
Re: calling on all jars in the folder(s): There are a lot of jars, because the
build process puts all the versions of them into the folder; I think some part
of the process needs all of them to build some kind of metadata.
The older Jars will already have been signed (of course, once we get this whole
process figured out :-) ), so they should not be re-signed, I think.
------------------------------------
Re: delaying signing an RC until the vote passes: I too feel it might be
wasteful to do this for multiple release candidates; on the other hand, it does
"test" the signing. I wonder if the RC's could do the build using the "test"
signing service, and then have some (automated, foolproof (?)) post-vote process
to switch over to the official signing?
----------------------
Re: updating the top-level parent pom for all of this, cancelling pending
releases - I think we can do this another way :-)
The idea would be to put the changes only into the Ruta parent pom for now.
Once it's worked out, then we can promote those to the overall build POM.
-Marshall
On 1/27/2016 5:34 AM, Peter Klügl wrote:
> Here are some first observations:
>
> - the ant task for the soap service should be called right before
> "Compress plugin Jars using pack200" (parent-pom: maven-antrun-plugin ->
> BuildUpdateSite-pack-svnget-buildMetadata-commit-to-dev)
> - in case the features are need to be signed, they have also to be
> copied to ${toBePacked} or something similar
> - the ant task should be called on all jars in that folder (or also an
> additional one for the features)
>
> Some consequences:
> - we would call the fee based signing service each time we build the
> update site with the apache-release profile. I actually do this
> sometimes to build snapshot update sites (a different solution is surely
> possible). However, we do this also for *every* release candidate. (For
> ruta, that would have been three times just because of some bugs). I do
> not have a good feeling about that. Maybe it's better to sign the
> bundles manually only for accepted release candidates (with additional
> repack)?
> - in order to integrate the ant task, we need to change the parent pom.
> Meaning we need to do a parent pom release. Meaning we need to update
> the parent pom version in our update site. Meaning we have to cancel
> both release candidates.
>
> Any opinions?
>
> Best,
>
> Peter
>
>
>
>
> Am 27.01.2016 um 10:24 schrieb Peter Klügl:
>> Marshall, are you able to access the test system?
>>
>> https://test-securesigning.websecurity.symantec.com/csportal/
>>
>>
>> Am 27.01.2016 um 10:17 schrieb Peter Klügl:
>>> Am 26.01.2016 um 22:09 schrieb Marshall Schor:
>>>> On 1/26/2016 5:20 AM, Peter Klügl wrote:
>>>>> ...
>>>>> ect all this info...
>>>>> Should we just copy the implementation to some of our (build) projects?
>>>> It would be good to automate this of course. I think that would take
>>>> using the
>>>> SOAP interface with the Ant script done by the Apache TomCat project.
>>>> However, some basic info on our web site for posterity once we forget how
>>>> this
>>>> all works would be good - pointers to other pages that describe how it all
>>>> works, how to use the test stuff, etc.
>>>> -Marshall
>>>>
>>> Yes, I will create/extend a page once it is up and running.
>>>
>>> Best,
>>>
>>> Peter
>>>
>
