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 >> >> >
