[
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"
|
Hi,
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] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> [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?
Tom
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_* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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
> https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29
>
>
> 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_*
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510#c27>. 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
> <https://wiki.eclipse.org/JarProcessor_Options#Other_properties>, no
> mater which version of Java you are using.
>
> Naturally, feel free to comment in *_Bug 463510_*
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=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
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck