You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2017/10/10 15:34:24 UTC
signing Eclipse Plugins - a proposed approach
I've documented a proposed approach on the website:
https://uima.apache.org/dev-eclipse-plugin-signing
This can also be reached from the
home page ->
(left nav bar) Eclipse Update Sites ->
Information for developers ->
information about plugin signing
The basic idea is a 2 phase approach - the first phase is normal, like now, no
signing, producing the release candidate to vote on. Once the Vote passes, then
a simple/mechanical repackaging of the update site is done, including signing,
with just a sanity check at the end that the result installs:
1. run the ant script "prepare-to-sign"
2. manually sign on to the signing portal, upload the jars in
target/eus-work/plugins, sign them, and download the signed jars to
target/eus-work-signed/plugins
3. run the ant script "finish-after-signing"
This avoids charging Apache for signing for release candidates that subsequently
fail. Because the actions following the vote are only mechanical "binary"
packaging, I think we don't need another vote.
I'm working on making the ant scripts for this, using the uimaj-v3 as the guinea
pig.
WDYT?
-Marshall
Re: signing Eclipse Plugins - a proposed approach
Posted by Marshall Schor <ms...@schor.com>.
second attempt - signed the feature jars, too.
Got the same "unsigned content" warning, but this time I continued, and to my
surprise, it asked me if I trusted these certificates (and it showed the
Symantec "TEST" signing certificate) - I said yes, and it completed. So I guess
that counts as working.
To be determined: it might have worked without signing the feature jars - but
probably it's better to have all the (jar) artifacts signed anyways.
To be determined later, see if the production signing makes the "unsigned
content" warning go away.
-Marshall
On 10/10/2017 11:43 AM, Marshall Schor wrote:
> one improvement - will document shortly on website:
>
> skip step 1 - no need to "prepare-to-sign".
>
> Instead, (after a small fix to the normal build) take all the Jars in the
> target/eus-work/plugins that are *.jar files, and sign these.
>
> This is of course, better, in that it doesn't "rebuild them".
>
> -Marshall
>
>
> On 10/10/2017 11:34 AM, Marshall Schor wrote:
>> I've documented a proposed approach on the website:
>> https://uima.apache.org/dev-eclipse-plugin-signing
>>
>> This can also be reached from the
>> home page ->
>> (left nav bar) Eclipse Update Sites ->
>> Information for developers ->
>> information about plugin signing
>>
>> The basic idea is a 2 phase approach - the first phase is normal, like now, no
>> signing, producing the release candidate to vote on. Once the Vote passes, then
>> a simple/mechanical repackaging of the update site is done, including signing,
>> with just a sanity check at the end that the result installs:
>>
>> 1. run the ant script "prepare-to-sign"
>> 2. manually sign on to the signing portal, upload the jars in
>> target/eus-work/plugins, sign them, and download the signed jars to
>> target/eus-work-signed/plugins
>> 3. run the ant script "finish-after-signing"
>>
>> This avoids charging Apache for signing for release candidates that subsequently
>> fail. Because the actions following the vote are only mechanical "binary"
>> packaging, I think we don't need another vote.
>>
>> I'm working on making the ant scripts for this, using the uimaj-v3 as the guinea
>> pig.
>>
>> WDYT?
>>
>> -Marshall
>>
>>
>
Re: signing Eclipse Plugins - a proposed approach
Posted by Marshall Schor <ms...@schor.com>.
First attempt: did a test signing of the 8 jars in the plugin dir. Didn't
succeed - Looks like maybe you need to sign the Jars used for features too. I'm
trying that next. -Marshall
On 10/10/2017 11:43 AM, Marshall Schor wrote:
> one improvement - will document shortly on website:
>
> skip step 1 - no need to "prepare-to-sign".
>
> Instead, (after a small fix to the normal build) take all the Jars in the
> target/eus-work/plugins that are *.jar files, and sign these.
>
> This is of course, better, in that it doesn't "rebuild them".
>
> -Marshall
>
>
> On 10/10/2017 11:34 AM, Marshall Schor wrote:
>> I've documented a proposed approach on the website:
>> https://uima.apache.org/dev-eclipse-plugin-signing
>>
>> This can also be reached from the
>> home page ->
>> (left nav bar) Eclipse Update Sites ->
>> Information for developers ->
>> information about plugin signing
>>
>> The basic idea is a 2 phase approach - the first phase is normal, like now, no
>> signing, producing the release candidate to vote on. Once the Vote passes, then
>> a simple/mechanical repackaging of the update site is done, including signing,
>> with just a sanity check at the end that the result installs:
>>
>> 1. run the ant script "prepare-to-sign"
>> 2. manually sign on to the signing portal, upload the jars in
>> target/eus-work/plugins, sign them, and download the signed jars to
>> target/eus-work-signed/plugins
>> 3. run the ant script "finish-after-signing"
>>
>> This avoids charging Apache for signing for release candidates that subsequently
>> fail. Because the actions following the vote are only mechanical "binary"
>> packaging, I think we don't need another vote.
>>
>> I'm working on making the ant scripts for this, using the uimaj-v3 as the guinea
>> pig.
>>
>> WDYT?
>>
>> -Marshall
>>
>>
>
Re: signing Eclipse Plugins - a proposed approach
Posted by Marshall Schor <ms...@schor.com>.
one improvement - will document shortly on website:
skip step 1 - no need to "prepare-to-sign".
Instead, (after a small fix to the normal build) take all the Jars in the
target/eus-work/plugins that are *.jar files, and sign these.
This is of course, better, in that it doesn't "rebuild them".
-Marshall
On 10/10/2017 11:34 AM, Marshall Schor wrote:
> I've documented a proposed approach on the website:
> https://uima.apache.org/dev-eclipse-plugin-signing
>
> This can also be reached from the
> home page ->
> (left nav bar) Eclipse Update Sites ->
> Information for developers ->
> information about plugin signing
>
> The basic idea is a 2 phase approach - the first phase is normal, like now, no
> signing, producing the release candidate to vote on. Once the Vote passes, then
> a simple/mechanical repackaging of the update site is done, including signing,
> with just a sanity check at the end that the result installs:
>
> 1. run the ant script "prepare-to-sign"
> 2. manually sign on to the signing portal, upload the jars in
> target/eus-work/plugins, sign them, and download the signed jars to
> target/eus-work-signed/plugins
> 3. run the ant script "finish-after-signing"
>
> This avoids charging Apache for signing for release candidates that subsequently
> fail. Because the actions following the vote are only mechanical "binary"
> packaging, I think we don't need another vote.
>
> I'm working on making the ant scripts for this, using the uimaj-v3 as the guinea
> pig.
>
> WDYT?
>
> -Marshall
>
>