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: [email protected] 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 > [email protected] > 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 _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
