Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Notice of change to batch "signing service"


Not sure this is related but I've now seen my build failing because of
pack200 and on the next run succeeding.

The last failure was:
> [INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
> [INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack (pack200-pack) on project org.eclipse.fx.core.guice: Execution pack200-pack of goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack failed: MALFORMED
> [DEBUG] Closing connection to remote
> [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack (pack200-pack) on project org.eclipse.fx.core.guice: Execution pack200-pack of goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack failed: MALFORMED -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1]
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :org.eclipse.fx.core.guice
> [DEBUG] Waiting for process to finish
> [DEBUG] Result: 1
> Sending e-mails to: tom.schindl@xxxxxxxxxxxxxxx

I've never seen these failures so I'm not sure they are related to the
change mentioned?


On 11.04.15 08:48, David M Williams wrote:
> I wanted to let everyone know that "we" are changing the version of
> Java's pack200 at the infrastructure service I call "batch signer".
>  (*_Bug 463510_* <>)
> It was using Java 6 level of pack200, and we have moved to the Java 8
> level of pack200.
> This command is described at
> This does not directly impact Tycho users or Buckminster users (which do
> their own re-pack and pack, based on the VM the build is running, I
> assume) but might effect PDE users, which traditionally have used this
> service to "re-pack" (condition) and sign jars -- and, then at some
> short later time are "packed".  At that "some later time", it is the
> release engineers responsibility to use the same version to 'pack' as
> was used to 'repack'.
> While no direct impact to Tycho or Buckminster builders, the principles
> and consequences of moving from one level (Java 6) to another (Java 8)
> apply with any builder, so the following points may be useful
> information to all.
> If you have "old byte codes", or, even new ones, compiled at the Java 4,
> Java 5, or Java 6 level, you *might* find some of those bytes codes no
> longer survive the "re-pack", sign, and "pack" process (where as maybe
> the would survived, when using Java 6 to run your build (and hence your
> repack/pack). That is, if user tries to download the pack.gz file, and
> unpack into a normal jar, it may be reported to have in "invalid
> signature" or in some other way "broken".
> In my experience, with Orbit jars, the "error rate" is about 1.7%.
> Others, for some unknown reason, see higher rates (such as 20-30%?) .
> Some of these cases *might* be bugs in the pack/unpack programs, but
> it's just as likely that there are "bugs" (fringe cases) where the byte
> codes for lower levels of Java are not quite "right".  All I know for
> sure: it has never been perfect.
> But, luckily, easy to solve.
> All three builders (PDE, Tycho, and Buckminster) allow you to specify an
> 'eclipse.inf' file in the META-INF directory, with a directive (line)
> that is:
>   jarprocessor.exclude.pack*=true*
> Thus, that one problematic jar is not packed, but is still signed.
> So important point 1: be sure you "pack200" with the same version you
> used to do "repack" (if the builder doesn't do it for you automatically).
> Important point 2: I wouldn't recommend studying the byte codes and
> trying to find a pattern of code that is the cause (unless you just
> happen to love byte codes), ... just slap in an eclipse.inf file and
> move on to more important things.
> Important point 3: You should not, ever never, "re-sign" and certainly
> not re-pack or pack200 a jar that has already been signed or processed
> by pack200. That pretty much guarantees the jar will be broken. In more
> ways than one. (*_Bug 461669_*
> <>)  
> The reason for making this move, now, is that it is best to "keep up"
> with what our users are using, and, with versions of Java that are
> expected to stay in service for a while ... otherwise, we might have to
> monkey around with this during a service release, which is less than ideal.
> * Bonus, for reading this far in my wordy note: Why jump two levels,
> from 6 to 8, why not move to Java 7 first? Well it turns out, at the
> moment, the versions of pack200 and unpack200 that ship with Java 7 and
> Java 8 are exactly the same
> <>. But, the
> advantage is, in some service release, there might be a new version and
> we'd pick it up automatically, as long as we use
> */shared/common/jdk1.8.0_x86-latest* consistently.  Double bonus:
> remember that pack200 and unpack200 have little to do with Java source
> code they are stand-alone executables, written in C-code, that simply
> manipulate byte codes. Which is how p2 can let you specify any version
> of pack200 you want
> <>, no
> mater which version of Java you are using.
> Naturally, feel free to comment in *_Bug 463510_*
> <>if any questions
> or concrete problems known.
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Thomas Schindl, CTO EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Back to the top