Re: redesigining our Eclipse plugin release build flow - list of issues to find out about

2017-09-22 Thread Peter Klügl
Kudos to you for approaching this. I'll try to help where I can, but I am very committed to other things right now :-( (Maybe in two weeks, I'll have more time) Best, Peter Am 20.09.2017 um 17:34 schrieb Marshall Schor: > I'm starting to think about redoing our Eclipse Plugin release

Re: redesigining our Eclipse plugin release build flow - list of issues to find out about

2017-09-20 Thread Marshall Schor
one more item: We could change how we release Eclipse plugins, and break the version lock-step which causes each version to release all the plugins, even when no change has happened in the plugins (as is often the case!) This would reduce the new JAR signings, by quite a bit, I think. -Marshall

Re: redesigining our Eclipse plugin release build flow - list of issues to find out about

2017-09-20 Thread Marshall Schor
one more "topic" to consider: If we abandon pack200 for compression, we could still use it for repacking, or JAR "normalization". pack200 has 2 phases; the first does things which change the JAR content/structure: 1. merges/sorts constant-ppol data in the class files and co-locates them 2.

redesigining our Eclipse plugin release build flow - list of issues to find out about

2017-09-20 Thread Marshall Schor
I'm starting to think about redoing our Eclipse Plugin release flow.  I'm hoping to start a thread where people can post answers to issues (there are many...). Motivation: start using the Symantec signing process for Jars (in addition to the PGP Apache signing process), so that Eclipse, when